When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug
1733492, the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI, and automatically migrate a false value for
browser.download.improvements_to_download_panel to a true value for this
pref. I'm updating some tangentially related test files since they
happen to be touched slightly by this change. Strictly speaking they
would still work, but if the pref value was somehow changed from the
default they would fail.
Differential Revision: https://phabricator.services.mozilla.com/D143002
In addition, if someone has pdf set to open internally but then disables the pdf viewer, an error occurs when trying to view a pdf. Handle this case by just asking what to do.
Differential Revision: https://phabricator.services.mozilla.com/D143313
This patch effectively enables the disallow relaxing referrer policies
for top navigations in ETP strict mode. It adds a ETP strict flag 'rpTop'
and set it in the strict feature list.
Differential Revision: https://phabricator.services.mozilla.com/D141869
We've made a few changes to this "Top pick" checkbox recently based on shifting
Product requirements, and the problem here is that the checkbox used to be
inside the Firefox Suggest container, but we recently moved it outside the
container. The Firefox Suggest container is properly hidden or shown depending
on whether the Suggest feature is enabled, so when the checkbox was inside the
container and Suggest was disabled, the checkbox properly got hidden too. Now
that the checkbox is outside that container, its visibility needs to entirely
depend on whether the best match feature is enabled.
So all this revision does is move the checkbox's `hidden` assignment from inside
the "is Suggest enabled" if-block to outside the if-block. It also sets
`hidden=true` on the checkbox in the markup for good measure.
I also improved the test so it checks every combination of enabled statuses
between the Suggest and best match features.
Depends on D138987
Differential Revision: https://phabricator.services.mozilla.com/D139161
We've made a few changes to this "Top pick" checkbox recently based on shifting
Product requirements, and the problem here is that the checkbox used to be
inside the Firefox Suggest container, but we recently moved it outside the
container. The Firefox Suggest container is properly hidden or shown depending
on whether the Suggest feature is enabled, so when the checkbox was inside the
container and Suggest was disabled, the checkbox properly got hidden too. Now
that the checkbox is outside that container, its visibility needs to entirely
depend on whether the best match feature is enabled.
So all this revision does is move the checkbox's `hidden` assignment from inside
the "is Suggest enabled" if-block to outside the if-block. It also sets
`hidden=true` on the checkbox in the markup for good measure.
I also improved the test so it checks every combination of enabled statuses
between the Suggest and best match features.
Depends on D138987
Differential Revision: https://phabricator.services.mozilla.com/D139161
We've made a few changes to this "Top pick" checkbox recently based on shifting
Product requirements, and the problem here is that the checkbox used to be
inside the Firefox Suggest container, but we recently moved it outside the
container. The Firefox Suggest container is properly hidden or shown depending
on whether the Suggest feature is enabled, so when the checkbox was inside the
container and Suggest was disabled, the checkbox properly got hidden too. Now
that the checkbox is outside that container, its visibility needs to entirely
depend on whether the best match feature is enabled.
So all this revision does is move the checkbox's `hidden` assignment from inside
the "is Suggest enabled" if-block to outside the if-block. It also sets
`hidden=true` on the checkbox in the markup for good measure.
I also improved the test so it checks every combination of enabled statuses
between the Suggest and best match features.
Depends on D138987
Differential Revision: https://phabricator.services.mozilla.com/D139161
This is based on part 1 in D138583. It hides the best match toggle switch when
the best match feature is disabled. The best match feature is a sub-feature of
Firefox Suggest, so the toggle is also hidden if Suggest is disabled, along with
all the other Suggest UI.
Depends on D138583
Differential Revision: https://phabricator.services.mozilla.com/D138584
- Show data collection section in about:preferences#privacy when privacy segmentation
section is enabled.
This is to ensure we can always show the privacy segmentation checkbox, even if data
reporting is disabled.
- Add checkbox and learnMore label for privacy segmentation pref.
- Add pref for section visibility and learnMore link suffix.
- Provisional copy, final copy to be added in Bug 1752172.
Differential Revision: https://phabricator.services.mozilla.com/D136650
- Show data collection section in about:preferences#privacy when privacy segmentation
section is enabled.
This is to ensure we can always show the privacy segmentation checkbox, even if data
reporting is disabled.
- Add checkbox and learnMore label for privacy segmentation pref.
- Add pref for section visibility and learnMore link suffix.
- Provisional copy, final copy to be added in Bug 1752172.
Differential Revision: https://phabricator.services.mozilla.com/D136650
These were all areas that were confusing me when I was onboarding on to
this code, so I tried to make the terminology less ambiguous and more
precise.
The default language is now the primary language.
UI is now appended to words that are dealing with DOM elements rather
than data stores.
Differential Revision: https://phabricator.services.mozilla.com/D136019
