This was added in bug 1559697 , to show the Close button on macOS.
It had unwanted side effects, including the appearance of buttons
that don't have any apparent effect. To resolve this regression,
the change is undone.
Differential Revision: https://phabricator.services.mozilla.com/D49746
--HG--
extra : moz-landing-system : lando
When `nsTextEditorState::SetValue()` is called with `eSetValue_BySetUserInput`,
we emulate user input. I.e., keep using transaction manager of the editor,
events fired while handling user input should be fired.
Currently, `nsTextEditorState::SetValue()` suppresses multiple state handling
while setting value with calling `mTextListener->SettingValue(true)`. This
is why `"input"` event listeners cannot retrieve the latest state of validation
if `inputType` is `"insertReplacementText"`.
This patch makes it keep managing `mTextListener` when setting the value
programatically. Otherwise, i.e., it emulates user input, editor should
manage it from `EditorBase::NotifyEditorObservers()` instead so that this
patch makes it not managing `mTextListener` in such case.
Differential Revision: https://phabricator.services.mozilla.com/D49571
--HG--
extra : moz-landing-system : lando
* Make about:networking work on mobile
* I used the aboutMemory.css file as a guide for doing this
* The mobile CSS does not include the common.css, since that doesn't seem to work. But at least now the interfaces is functional. We should make it look nice in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D49582
--HG--
extra : moz-landing-system : lando
* Make about:networking work on mobile
* I used the aboutMemory.css file as a guide for doing this
* The mobile CSS does not include the common.css, since that doesn't seem to work. But at least now the interfaces is functional. We should make it look nice in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D49582
--HG--
extra : moz-landing-system : lando
The XPInstall content handlers currently make all sorts of assumptions about
the process they're being run in and the docShell their request is tied to.
These assumptions don't hold under Fission, either now, when they may be
called just after a process switch, or in the future, when they'll be called
in the parent process.
This patch updates them to operate on the BrowsingContext of the request, and
to do their messaging via the process message manager, rather than via frame
message managers. As a bonus, it also removes the existing hacks they had in
place to handle the cases where frame message managers didn't work.
Differential Revision: https://phabricator.services.mozilla.com/D48224
--HG--
extra : moz-landing-system : lando
This change will cause Firefox to re-download the OpenH264 GMP if it already has
the 1.8.1 version. This is being done to mitigate and issue where clients that
already downloaded that version on previous versions of Firefox did not clear
the mac quarantine attribute that prevents the lib being loaded in MacOS
Catalina.
Newer versions of Firefox will clear the attribute on download, so we want to
trigger a re-download by those clients. We would typically expect this to be
done by balrog, but we update these fallback rules to cover the edge case where
balrog is not available and in order to keep these rules in step with those on
balrog.
The binaries pointed to by this 1.8.1.1 version are the same as the 1.8.1
version. This change is solely to trigger a re-download.
Differential Revision: https://phabricator.services.mozilla.com/D49197
--HG--
extra : moz-landing-system : lando
To make us pass flash blocking testcases when fission is enabled, we should use
SpecialPowers.spawn instead of ContentTask.spawn because the iframes in the testcases
may be cross-origin iframes.
Differential Revision: https://phabricator.services.mozilla.com/D49388
--HG--
extra : moz-landing-system : lando
This added test, browser_thirdPartyIframe.js, is disabled for Fission until
we get Picture-in-Picture support working for it (Bug 1576915).
Differential Revision: https://phabricator.services.mozilla.com/D48201
--HG--
extra : moz-landing-system : lando
All but browser_bug744745.js seem to pass even without the fixes I
made, which seems odd.
browser_bug1058164.js is a little odd because it passes in {} instead
of a boolean for the useCapture argument. I think this ends up calling
addEventListener(..., {}, false), which should be the equivalent of
addEventListener(..., {}).
Differential Revision: https://phabricator.services.mozilla.com/D49453
--HG--
extra : moz-landing-system : lando
Bug 1586683 replaced the JS_FlattenString in the caller with JS_EnsureLinearString but
I wasn't aware of the nsDependentString vs nsDependentSubstring distinction.
This fixes assertion failures when starting the browser with non-null-terminated
JS strings.
Differential Revision: https://phabricator.services.mozilla.com/D49297
--HG--
extra : moz-landing-system : lando