Account for the border and padding now on the inner arrowscrollbox, and increase some window and margin
sizes to account for the menu being larger in Windows 10.
Differential Revision: https://phabricator.services.mozilla.com/D110587
This never actually worked, because nothing ever listened to the notification
sent in XPCJSContext (kill-content-script-sandbox). We're also removing the
"Temporarily disable extension" button in the slow addon notification, which
was the primary caller of this - however, that's in a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D110583
Fairly straightforward - this removes the button from the slow add-on script
notification, as well as the functions that only it utilizes.
Differential Revision: https://phabricator.services.mozilla.com/D110582
This code didn't make it across when we reworked how we record our playback
probes. However, it's a useful checksum to compare against our Widevine
playtime + as a general data point. This patch restores the code to record the
probe.
Differential Revision: https://phabricator.services.mozilla.com/D107072
Expands the EME telemetry test to cover two additional cases.
1. The EME media is loaded but before playback the src is switched to unecrypted
media. In this case, we don't expect encrypted playtime to be recorded, but
we will still collect clearkey playtime as the element still has clearkey
media keys attached.
2. Same as the above, but where the media keys are also cleared. In this case we
do not expect either encrypted or clearkey time to be recorded.
Differential Revision: https://phabricator.services.mozilla.com/D110550
This changeset adds a test to verify that playtime telemetry related to EME is
gathered after playing an encrypted file. It does so by checking that the
VIDEO_ENCRYPTED_PLAY_TIME_MS and VIDEO_CLEARKEY_PLAY_TIME_MS are the same as the
VIDEO_PLAY_TIME_MS after playing an encrypted file (this may not always happen
in the wild, but should hold for test).
To support this test I've added a new eme helper file `eme_standalone.js` this
is an EME helper with no extra dependencies. This allows it to be used in normal
mochitests and browser mochitests, rather than just one or the other. It is also
not coupled with the media mochitests (and `manifest.js`) unlike our existing
EME helpers, so should be more portable.
Differential Revision: https://phabricator.services.mozilla.com/D110446
This allows getting bugs get filed into the correct component (e.g. from
Treeherder for test failures or from Searchfox which mentions the component
at the top right in the file view).
Differential Revision: https://phabricator.services.mozilla.com/D108951
Currently, it dispatches `input` event with holding `mPlaceholderTransaction`
and `mPlaceholerBatch` as 1. If `input` event listener sets value in XUL
document, the setting value transaction will break the existing placeholder
transaction. Then, only the last one will be undone, and it causes inserting
new padding `br` element with transaction and clears redo history.
This patch makes it forget them before dispatching `input` event.
Note that I tried to create automated test for this, but I cannot reproduce
this with simple testcase. I guess something other things also required to
reproduce this bug.
Differential Revision: https://phabricator.services.mozilla.com/D110715
When `--backgroundtask TASK` invocations exit, they try to remove
their temporary profile directory. This mostly works, except there
are some very late writes to the profile directory including
`Telemetry.ShutdownTime.txt` and the `security_state` directory. This
commit accommodates by moving the profile directory removal even
later. It might be possible to instead avoid these very late writes,
but that is hard in general, and is more likely to depend on the exact
code invoked by the background task itself.
Differential Revision: https://phabricator.services.mozilla.com/D110472
It's very unlikely that this would make a difference, since creating
the service does not immediately look for a profile. But it's also
not clear to me why I originally placed it after the service was
created, and it's not impossible that the service creation would look
for `XRE_PROFILE_PATH` (which is how we communicate the desired
profile to the profile service), so let's create the profile before
the service.
Differential Revision: https://phabricator.services.mozilla.com/D110309
This also removes the 10.14+ check, so that on 10.12 & 10.13 we always set
currentAppearance to aqua. This preserves RenderWithCoreUI's behavior.
Depends on D110763
Differential Revision: https://phabricator.services.mozilla.com/D110764
The `scale_factors` method for `ScaleOffset` needs to take the absolute
value of the scale field, which is the same way that scale factors
are calculated in the slower transform based path. These scale factors
are used to determine the appropriate size of an offscreen surface in
some cases.
Differential Revision: https://phabricator.services.mozilla.com/D110726
The first part fixes the bookmarks sidebars etc when in a light theme.
The second fixes too-light selection colors in websites.
Differential Revision: https://phabricator.services.mozilla.com/D110729
This matches Chrome and Safari, as well as what we do for all other <input>s.
<input>s were changed to inline block in 1539469 with a couple of font inflation reftests marked as failing to follow up on. https://hg.mozilla.org/mozilla-central/rev/a1201db1b8cc is the follow up which made inputs not be font inflation containers. The same change for textarea fixes similar reftest failures for textarea. I read through the commit message for the change and doing the same for textareas seems to make sense but I don't understand it in detail.
Differential Revision: https://phabricator.services.mozilla.com/D109603
After this patch, there are two remaining pieces to fix bug 1700294:
* macOS nsLookAndFeel needs to return the right colors for light / dark
appearance.
* We need to return ColorScheme::Dark for the right documents in
ColorSchemeForDocument.
Both of those should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D110680
