Most of things will likely be no real change because they ask for the exact frame they want immediately before.
Differential Revision: https://phabricator.services.mozilla.com/D44359
--HG--
extra : moz-landing-system : lando
This also fixes some of the issues with -moz-image-region, where we just minted
an auto out of the blue.
Depends on D43472
Differential Revision: https://phabricator.services.mozilla.com/D43474
--HG--
extra : moz-landing-system : lando
performAction, performActionOnRow and performActionOnCell are methods of the
nsITreeView interface that are never called. This is to remove these methods.
A comm-central patch will be along shortly.
Differential Revision: https://phabricator.services.mozilla.com/D39273
This is consistent with the `order` property anyhow, and allows to simplify some
code.
Negatives are still not parsed, but rust uses a similar representation for all
CSS <integer> values and so should C++.
Differential Revision: https://phabricator.services.mozilla.com/D42912
--HG--
extra : moz-landing-system : lando
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Now, `TextEditRules` should use the new editor API to mask/unmask characters
if it's for a password editor. With this change, it does not need to manage
masked characters and unmasked characters separately since the anonymous
text node always have unmasked characters and `nsTextFrame` will mask the
characters at painting time.
Differential Revision: https://phabricator.services.mozilla.com/D38005
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
This will have two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D35870
--HG--
rename : dom/xul/test/test_bug486990.xul => dom/xul/test/test_bug486990.xhtml
rename : layout/base/tests/file_bug465448.html => layout/base/tests/chrome/file_bug465448.html
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D34782
--HG--
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
Cameron McCormack
Ting-Yu Lin
Timothy Nikkel
Sylvestre Ledru
Emilio Cobos Álvarez
Alex Vincent
Mats Palmgren
Nathan Froyd
Brendan Dahl
L. David Baron
Kannan Vijayan
Nicholas Nethercote
Edwin Gao
Bogdan Tara
Masayuki Nakano
RuchikaGosain
Brindusan Cristian
Alexis Beingessner
Thomas Nguyen
Boris Zbarsky
Dorel Luca
Victor Porof
Gerald Squelart
Mihai Alexandru Michis
Will Hawkins
Neil Deakin