This gcc 4.8.5 workaround (from bug 1316850) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
MozReview-Commit-ID: 4JFmOYoJnMH
--HG--
extra : rebase_source : f348a629f25f6852250306d969262372460a677a
extra : source : cb42b2192694148ffdf97c3a5c2fabb2578a0ec0
This gcc 4.9.2 workaround (from bug 1273048) is no longer needed because Firefox for Android now uses clang instead of gcc (as of bug 1163171).
The gcc bug was fixed in gcc 4.8.5 and 4.9.3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037
MozReview-Commit-ID: IAKONNSkqcz
--HG--
extra : rebase_source : 643dd54bb2fba5c42dc2fd94d037c4867c48aaf9
extra : source : c0a136d3504df14eef7f03e3a5588a47519035d5
Firefox currently requires gcc 6.1 or later (as of bug 1444274).
MozReview-Commit-ID: CaJwpUgntxn
--HG--
extra : rebase_source : 302d8aa57696e2e96962c67e3497f76e882a472f
extra : source : 2a53a830f79424b2c41c8bdc4816ec24fa943ecc
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : 251574d238ded31b9df32dc89852251831d55757
extra : source : c53c7b0249ad3359fbc9f144f2cf9ca3b6386c59
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : 1702e63fed719fc92def2bdbbb8a7c53572432db
extra : source : 41bedc526dd6ec6b7e8c7be1c832ac60c81d6263
Summary:
Implemented by nsDocShell and nsWebBrowser (which just wraps the
docshell functions), but not actually used anywhere.
MozReview-Commit-ID: 2YzfsrvOolX
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480641
Differential Revision: https://phabricator.services.mozilla.com/D2695
The patch of part 1 changed the behavior of clicking the meatball button.
So this patch will fix the related test.
Differential Revision: https://phabricator.services.mozilla.com/D2585
--HG--
extra : rebase_source : ddacf0f0a4da73cef8a91731eb7326e286d2f83d
extra : amend_source : 86066fd3fbc25447c2ec98b06fbf11da93578df1
The menu button can't receive the key event on macOS since macOS doesn't leave the focus of the menu button even if click the menu button.
So this patch will add the focus to the button when clicking the button.
Differential Revision: https://phabricator.services.mozilla.com/D2585
--HG--
extra : rebase_source : 0cb9064790c6d75c61fccc51b14faf6ddf00f98e
extra : amend_source : 122dbced9ac858edfb9b55fad0a2b6ad1f398b52
Summary:
Only implemented by nsWebBrowser, only 2 methods used in TabChild.
Move methods to nsWebBrowser implementation and remove unused methods,
change names to something more obvious, and remove interface.
MozReview-Commit-ID: 4WwBrVWQEVy
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480645
Differential Revision: https://phabricator.services.mozilla.com/D2752
Summary:
We only use one branch of the property set method in
nsIWebBrowserSetup, in one place. Expose this setting in the C++ API
and remove the XPCOM interface.
This patch also exposes the nsWebBrowser.h header to the codebase,
meaning we can possibly start removing some uses of nsIWebBrowser
elsewhere.
MozReview-Commit-ID: G3gnRWJUx6M
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480643
Differential Revision: https://phabricator.services.mozilla.com/D2736
Summary:
Unused interface that can be removed.
MozReview-Commit-ID: GnHRXdtI4qe
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480637
Differential Revision: https://phabricator.services.mozilla.com/D2694
Summary:
nsIWebShellServices is only implemented by nsDocShell, and only used
in one place in C++. Move definitions to nsIDocShell, and rename
functions to show they are only used as part of Charset changes.
MozReview-Commit-ID: DOSeE3Doc51
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480628
Differential Revision: https://phabricator.services.mozilla.com/D2692
This fixes the regression of three web-platform-test reftests:
testing/web-platform/tests/css/css-contain/contain-paint-002.html
testing/web-platform/tests/css/css-contain/contain-paint-011.html
testing/web-platform/tests/css/css-contain/contain-paint-012.html
that was caused by patch 1, but it's written on top of the code in
patches 2 and 3 so it's easier to fix afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2812
--HG--
extra : rebase_source : 030c72d1f2945795afe8a81112cd6cb7035d9d6b
This is needed for patch 4.
This is based both on the wording in the spec and the discussion in
https://github.com/w3c/csswg-drafts/issues/2987, and also doesn't
support them for nsMathMLContainerFrame, which is similar to inlines and
ruby.
Differential Revision: https://phabricator.services.mozilla.com/D2815
--HG--
extra : rebase_source : b7e23fb248fa34957ca2d539134e872f5a03f5a8
This fixes a rather subtle bug. What the underlying code here is trying
to do is remove nsChangeHint_UpdateContainingBlock when some properties
that influence whether a frame is a containing block for absolutely
positioned or fixed positioned elements have changed, but the final
calculation of being a containing block has not changed. However, the
old code was using a function that tested whether the style could
*possibly* lead to a frame being a containing block. Some of the
properties (like the transform properties) that lead to being a
containing block, for example, don't apply to non-replaced inlines.
Some, however, do (such as 'filter'). So if there's a dynamic change
adding or removing a filter, on an inline that also has an *ignored*
transform property (like 'transform' or 'perspective') set, then the
code prior to this patch causes us to remove the UpdateContainingBlock
hint.
This patch fixes things by testing whether being a containing block
could have changed for *any* type of frame, by separately testing the
changes.
The added tests fail without the patch and pass with the patch, viewed
in isolation. However, without the previous patch, test 003 passes.
Test 003 also fails in Chrome (but 001 and 002 pass).
Differential Revision: https://phabricator.services.mozilla.com/D2814
--HG--
extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
The basic change here is making nsCSSFrameConstructor::ConstructInline
use the function nsIFrame::IsAbsPosContainingBlock rather than testing
for only one of the conditions in it (being relatively or absolutely
positioned). The rest of the code changes follow from that change.
I tested locally that the added test fails without the patch and passes
with it (either with or without the next patch).
Note that this causes a regression of three web-platform-test reftests:
testing/web-platform/tests/css/css-contain/contain-paint-002.html
testing/web-platform/tests/css/css-contain/contain-paint-011.html
testing/web-platform/tests/css/css-contain/contain-paint-012.html
which will be fixed in patch 4, since that fix is easier to write after
patch 2.
Differential Revision: https://phabricator.services.mozilla.com/D2813
--HG--
extra : rebase_source : 0d374628207c234bcd7cf4e320188994fc2680b8
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : fa253abde2029ec09c724404106d83623f064875
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : c528dffe3a54eec75ad6cb358980b783b00eb4a4
Summary: When removing frames from the trackbuffer we may remove frames outside the original removal interval as we must remove all frames depending on the removed frames.
Differential Revision: https://phabricator.services.mozilla.com/D2837
PresShell does this already.
I updated the scroll / drag code as well, but I need to admit I didn't figure
out how to write a test for it. The rest of the codepaths are needed for the
added test to pass.
Differential Revision: https://phabricator.services.mozilla.com/D2871
We shouldn't fire mouseenter / leave based on the light tree, but the
flattened tree, the same way as the rest of the hover code works.
Differential Revision: https://phabricator.services.mozilla.com/D2866
parseDeclarations was ignoring html comment tokens, but in fact they
should not be treated any differently from other CSS tokens.
MozReview-Commit-ID: 27Mxt5zbSSJ
--HG--
extra : amend_source : 91e47bbf6951ac9dd4709ac10c49ff51c1781ce8
