nsIPresShell.h is widely included, so this avoids excessively long rebuilds
when MobileViewportManager.h is modified.
Differential Revision: https://phabricator.services.mozilla.com/D26245
--HG--
extra : moz-landing-system : lando
Toolbar buttons are only made focusable when accessed via the keyboard.
As soon as they lose focus, their focusability is removed.
This is done so that clicking them doesn't focus them.
Previously, this meant that if a panel opened, focus couldn't be restored to the button like it should be when the panel was closed, as the button was no longer focusable.
To work around this, use the open="true" attribute set on the button when the panel opens.
If this is detected when the button loses focus, focusability is not removed.
Once focus is restored after the panel closes, things continue as normal.
That is, when the button loses focus for some other reason, its focusability is removed.
Differential Revision: https://phabricator.services.mozilla.com/D26073
--HG--
extra : moz-landing-system : lando
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
--HG--
extra : moz-landing-system : lando
After bug 676268 is landed, Gecko/Android supports `text/html` mime type on
clipboard. But copy command is sometimes failed after select all is executed.
`nsISelectionContoller.selectAll` is different of `cmd_selectAll`.
Since `cmd_selectAll` that is used on Firefox desktop doesn't select root
element, copy command always works well. So we should use it like desktop
browser on Fennec.
Also, GV already uses cmd_selectAll on action bar, so this is Fennec only.
Differential Revision: https://phabricator.services.mozilla.com/D25924
--HG--
extra : moz-landing-system : lando
Otherwise, LTO will eliminate it because the compiler can't see the
calls to PrepareAndDispatch from the relevant assembly file.
Differential Revision: https://phabricator.services.mozilla.com/D26244
--HG--
extra : moz-landing-system : lando
ARM's xptcstubs use a slightly different setup for PrepareAndDispatch
than...well, all of our other stubs. This difference appears to be
causing problems with LTO builds. Change the setup to be more like our
other stubs, which additionally gets rid of some of the `asm` nonsense.
Differential Revision: https://phabricator.services.mozilla.com/D26243
--HG--
extra : moz-landing-system : lando
The original name of the profile is irrelevant here since we aren't testing
a migration to profiles-per-install. On dev-edition DEDICATED_NAME is the same
as PROFILE_DEFAULT so we correctly make a new profile with a unique name.
Differential Revision: https://phabricator.services.mozilla.com/D26230
--HG--
extra : moz-landing-system : lando
This fixes two bugs. The first is that when the firefox profile migrator doesn't
know which profile to migrate it attempts to fall back to another profile. I
think this was intended to be the default but in bug 1322797 I ended up making
it the current profile, which is the profile we're restoring into now. I think
at this stage the profile directory doesn't even exist so things go wrong.
Changing to use the actual default works but....
When the profile migrator UI doesn't know what profile to migrate from it uses
the default profile. So if the profile you're actually trying to restore is not
the default we'll effectively throw its data into the archive and replace it
with data from the default profile. I'm inclined to say that if the migrator
does not know what profile to migrate from it should error at that point for
safety.
Why would the profile migrator not know what profile to migrate from? Because of
a long-standing text encoding problem. In C++ profile names are encoded in UTF8.
But we try to pass them to JS through an IDL parameter of type ACString. This
does no UTF8 decoding and so JS recieves an incorrect name if the name includes
non-ascii characters and so can't find the profile.
This patch fixes the IDL parameter to AUTF8String which does the decoding
correctly and so JS gets the name correctly.
We should probably think about whether just passing the nsIToolkitProfile object
to the migrator is a better choice here.
Differential Revision: https://phabricator.services.mozilla.com/D26250
--HG--
extra : moz-landing-system : lando
This preserves the behavior of not having FontFace objects for @font-face rules
in display: none iframes.
Note, however that we may want to always track stylesheets to both not have this
limitation and to fix bug 1471231 & co. But that's a separate bug in any case.
The assertion that is failing ultimately in this bug is not really relevant
anymore, so remove it while at it.
Differential Revision: https://phabricator.services.mozilla.com/D26196
--HG--
extra : moz-landing-system : lando
This field now just caches the IsReflectable() field from the method
info, so get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D26071
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
There is only a single XPC JS runtime now, so there's no need to keep a
special pointer around.
Differential Revision: https://phabricator.services.mozilla.com/D26068
--HG--
extra : moz-landing-system : lando
Add the crash reporter port to the utility process sandbox so that crash reports can be saved for processes using the utility sandbox with early sandbox init.
At this time, the RDD process is the only process using the utility sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D26228
--HG--
extra : moz-landing-system : lando
When this handler got changed to an arrow function the reference didn't get
moved onto the scrollbox.
Differential Revision: https://phabricator.services.mozilla.com/D26142
--HG--
extra : moz-landing-system : lando
This fixes the filename and line number of login manager logs.
This is basically a rebased backout of the LMH portion of changeset b1e3cd7db269.
Differential Revision: https://phabricator.services.mozilla.com/D26023
--HG--
extra : moz-landing-system : lando
This makes sure that the mozharness scripts have access to all the packages in
the build system virtualenv (namely mozbase).
Differential Revision: https://phabricator.services.mozilla.com/D22184
--HG--
extra : moz-landing-system : lando
