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
This function doesn't use any StackingContextHelper state anymore.
We should make what it does clearer and move it to a better place.
--HG--
extra : rebase_source : 1727be9657169547d842ec9b6887837abedbefdf
Then, all classes in editor/txmgr is now in mozilla namespace and all
headers which are included by other directory are now exposed. So,
we can remote local includes from other directories now.
MozReview-Commit-ID: Kdb1c4Hp9Sy
--HG--
rename : editor/txmgr/nsTransactionStack.cpp => editor/txmgr/TransactionStack.cpp
rename : editor/txmgr/nsTransactionStack.h => editor/txmgr/TransactionStack.h
extra : rebase_source : 75035e9e618680af9188820595ab050b612a456f
Matt Woodrow
Emilio Cobos Álvarez
Brindusan Cristian
Boris Zbarsky
Chris Peterson
Timothy Guan-tin Chien
shindli
Adrian Wielgosik
Hiroyuki Ikezoe
Andrew McCreight
Sebastian Hengst
Tristan Bourvon
Nika Layzell
Noemi Erli
Jeff Muizelaar
Ciure Andrei
Bogdan Tara
Jonathan Watt
Masayuki Nakano
Narcis Beleuzu
Ryan Hunt