MALLOC_STATIC_PAGESIZE is only set on some platforms. Specifically, it's
not set on ia64 and sparc. Which means the case MALLOC_STATIC_PAGESIZE
&& (sparc || ia64) never happens, and gPageSize is never 8 KiB.
Differential Revision: https://phabricator.services.mozilla.com/D31965
--HG--
extra : moz-landing-system : lando
This will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
--HG--
extra : moz-landing-system : lando
The "add search engine" page action wants to use badged toolbarbuttons,
but it does this by adding the "badged-button" class (which changes the
XBL binding) after the button has already been created and added to
the DOM. To avoid having to switch between non-badged and badged buttons
when toolbarbutton is converted to custom elements, add a property to
page actions so that the badged status can be determined when the element
is created.
Differential Revision: https://phabricator.services.mozilla.com/D31940
--HG--
extra : moz-landing-system : lando
This code contains an undesirable dependency between the layout code and
the implementation of toolbarbutton. Since it isn't actually used anywhere
by the firefox UI, remove it here.
Differential Revision: https://phabricator.services.mozilla.com/D31939
--HG--
extra : moz-landing-system : lando
This is essentially reverting the test changes from bug 653881. The
platform changes that motivated bug 653881 were reverted in bug 888787
but the test changes were left in place at that time.
Differential Revision: https://phabricator.services.mozilla.com/D31937
--HG--
extra : moz-landing-system : lando
The tests currently running against chromium do not expect the content blocking
to be enabled. So, to prevent breaking cookies/requests being done by the tests,
disable it by default when running the agent.
Differential Revision: https://phabricator.services.mozilla.com/D31993
--HG--
extra : moz-landing-system : lando
The node program (puppeteer) and/or the agent itself, will close Firefox brutaly
in some cases. So that when we reopen Firefox, the safe mode popup will be shown,
asking the user if he prefers to start in safe mode.
But that break the automation as we expect Firefox to be opening the browser window as usual.
Differential Revision: https://phabricator.services.mozilla.com/D31992
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando