Actually since the tagName may be things like "html:option" we need to
fix a couple other checks in the child actor, too, that was a
pre-existing bug with XHTML.
Differential Revision: https://phabricator.services.mozilla.com/D175150
- Rename RFPLite to privacy.fingerprintingProtection (FPP)
- Create two pbmode prefs that will enable RFP/FPP in PBMode
only. The original prefs will enable it in both modes.
- Make exempting Web Extensions the default behavior
- If there are website exemptions in the exemptedDomains pref,
exempt them unconditionally
- Use the timezone testing pref to determine whether or not we
call _tzset on Windows
Differential Revision: https://phabricator.services.mozilla.com/D174014
Experimentation confirmed years ago that about:welcome shoudln't be treated as blank for urlbar focus, and no need for additional experimentation. Also fix a bug where about:welcome was treated as a blank/empty page resulting in about:preferences incorrectly replacing it.
Differential Revision: https://phabricator.services.mozilla.com/D174940
Err, so the original patch is necessary but not sufficient, and I
clearly goofed my testing (I had removed this attribute in a separate
commit).
The issue is that this button ends up with a markup like:
<button class="permission-popup-permission-remove-button">
<label flex="1" class="permission-popup-permission-state-label">Allowed Temporarily</label>
<hbox class="box-inherit button-box" align="center" pack="center" flex="1" anonid="button-box">
<image class="button-icon"/>
<label class="button-text"/>
</hbox>
</button>
So the label and hbox divide the available space in half. Removing any
of the flex="1" attributes would cause the desired rendering.
I don't think the hbox needs to be flexible tbh, but ok, that's a
riskier change. I'm pretty sure the label in this case doesn't need to
be flexible at all though, specially since we don't want these buttons
to take any minimum amount of space.
An alternative would be to use `flex: 1 auto` or so for the label (via
CSS). That'd match the pre-regression behavior more exactly, but again I
don't think flexing the label is needed at all.
Depends on D174706
Differential Revision: https://phabricator.services.mozilla.com/D174707
Add logic to apply theme colors to Feature Callout based on where it's
going to show. We can use in-content CSS properties for Firefox View and
other themed system pages, but not for PDF.js, nor for any callouts we
might show in the browser chrome in the future. For the browser chrome
in general, we can use the lightweight theme properties directly, in the
same way the chrome frontend does. But PDF.js is a special case, since
although it exists in the chrome, it's meant to appear like it's in the
PDF.js viewer. And the PDF.js viewer has its own theme totally
independent of everything else. So this dynamically applies themes from
different sources.
This also fixes the bug where the PDF.js color scheme could mismatch the
PDF.js viewer if the browser theme and system color scheme don't match,
e.g. where system color scheme is light but a dark theme is installed,
or vice versa. For PDF.js specifically, we can use the
-moz-content-prefers-color-scheme media query to follow the color scheme
as it exists in the PDF.js viewer page instead of the color scheme in
the chrome window where the Feature Callout actually exists.
It also adds or modifies some colors that were previously missing or
different from the prototype, fixes the illegibility of buttons in HCM
and forced colors mode, and makes some other minor color changes.
Differential Revision: https://phabricator.services.mozilla.com/D173088
Add logic to apply theme colors to Feature Callout based on where it's
going to show. We can use in-content CSS properties for Firefox View and
other themed system pages, but not for PDF.js, nor for any callouts we
might show in the browser chrome in the future. For the browser chrome
in general, we can use the lightweight theme properties directly, in the
same way the chrome frontend does. But PDF.js is a special case, since
although it exists in the chrome, it's meant to appear like it's in the
PDF.js viewer. And the PDF.js viewer has its own theme totally
independent of everything else. So this dynamically applies themes from
different sources.
This also fixes the bug where the PDF.js color scheme could mismatch the
PDF.js viewer if the browser theme and system color scheme don't match,
e.g. where system color scheme is light but a dark theme is installed,
or vice versa. For PDF.js specifically, we can use the
-moz-content-prefers-color-scheme media query to follow the color scheme
as it exists in the PDF.js viewer page instead of the color scheme in
the chrome window where the Feature Callout actually exists.
It also adds or modifies some colors that were previously missing or
different from the prototype, fixes the illegibility of buttons in HCM
and forced colors mode, and makes some other minor color changes.
Differential Revision: https://phabricator.services.mozilla.com/D173088
