DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
It's not needed anymore, since we tag the pseudo-elements at creation time for
styling.
Differential Revision: https://phabricator.services.mozilla.com/D2330
MozReview-Commit-ID: 7j4DVEHXYIC
Using references helps to see when stuff can and cannot be null.
I removed useless aTag / aNamespaceId arguments which are useless now that XBL
can't override them (bug 1450617), so FindXULData is the only one that keeps
them alive.
Also, I took the liberty of renaming a few fooComputedStyle variables to just
fooStyle, and clarify naming in some pseudo-element-related functions to say
originating element (the spec term) and avoid confusing it with the generated
_moz_generated_content_before / _moz_generated_content_after element.
Note that this is a partial state, more stuff will come in the future.
Differential Revision: https://phabricator.services.mozilla.com/D2326
MozReview-Commit-ID: 39B30doREUH
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Only <textarea> has GetWrapRows() > 0, and the rule for textarea disappeared in
bug 82711.
MozReview-Commit-ID: ERcoLVcufbH
--HG--
extra : rebase_source : 687ae89ce94e0e7f3682f434264661f7b9554819
We do the following:
CreateRootNode();
nsresult rv = BindToFrame(this);
NS_ENSURE_SUCCESS(rv, rv);
aElements.AppendElement(mRootNode);
That means that if BindToFrame fails, mRootNode will never be appended to
aElements, and thus will never get the native anonymous bits in [1].
BindToFrame should assert, but it indeed can fail due to it being bound to a
different frame in print preview, because nsCSSFrameConstructor's
ReplicateFixedFrames is a massive hack. :(
Just ensure the NAC bit is properly set for now...
[1]: https://searchfox.org/mozilla-central/rev/a85db9e29eb3f022dbaf8b9a6390ecbacf51e7dd/layout/base/nsCSSFrameConstructor.cpp#4193
MozReview-Commit-ID: 6sE8iUk4PCG
We do the following:
CreateRootNode();
nsresult rv = BindToFrame(this);
NS_ENSURE_SUCCESS(rv, rv);
aElements.AppendElement(mRootNode);
That means that if BindToFrame fails, mRootNode will never be appended to
aElements, and thus will never get the native anonymous bits in [1].
BindToFrame should assert, but it indeed can fail due to it being bound to a
different frame in print preview, because nsCSSFrameConstructor's
ReplicateFixedFrames is a massive hack. :(
Just ensure the NAC bit is properly set for now...
[1]: https://searchfox.org/mozilla-central/rev/a85db9e29eb3f022dbaf8b9a6390ecbacf51e7dd/layout/base/nsCSSFrameConstructor.cpp#4193
MozReview-Commit-ID: 6sE8iUk4PCG
We do the following:
CreateRootNode();
nsresult rv = BindToFrame(this);
NS_ENSURE_SUCCESS(rv, rv);
aElements.AppendElement(mRootNode);
That means that if BindToFrame fails, mRootNode will never be appended to
aElements, and thus will never get the native anonymous bits in [1].
BindToFrame should assert, but it indeed can fail due to it being bound to a
different frame in print preview, because nsCSSFrameConstructor's
ReplicateFixedFrames is a massive hack. :(
Just ensure the NAC bit is properly set for now...
[1]: https://searchfox.org/mozilla-central/rev/a85db9e29eb3f022dbaf8b9a6390ecbacf51e7dd/layout/base/nsCSSFrameConstructor.cpp#4193
MozReview-Commit-ID: 6sE8iUk4PCG
The label of the button comes from the UI; it's direction should be independent
of the web content directionality. As there is no access to :-moz-locale-dir()
selectors in HTML, we'll have to rely on auto-direction here.
The alternative (or, addition to the fix here) would be adding the value of
the dir attribute to HtmlForm.properties, allowing the localizers to set
the directionality explicitly. I however don't know if that's necessary.
MozReview-Commit-ID: 5NXeLtxLXVH
--HG--
extra : rebase_source : 724eb60ccd841d2355fc17ba31af3cf4792962ef
extra : source : 91d8903ab19812f36aa1732d35d0dc203b0f6281
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
Kris Maglione
Narcis Beleuzu
Morgan Rae Reschenberg
Emilio Cobos Álvarez
Andi-Bogdan Postelnicu
Boris Zbarsky
Jeff Gilbert
Daniel Holbert
Noemi Erli
Cameron McCormack
Mihir Iyer
Yusuf Sermet
Matt Woodrow
Brindusan Cristian
Chris Peterson
Timothy Guan-tin Chien
shindli
Adrian Wielgosik
Hiroyuki Ikezoe
Andrew McCreight