After bug 1338493 landed, HttpChannelChild might be released on STS thread.
Redirected channel, intercept stream listener and context might not always be able to
release off-main-thread. Therefore, we need to proxy release these members on main thread.
MozReview-Commit-ID: 6mcja7WY1fK
--HG--
extra : rebase_source : 55999dfa63b81347e426d90a59e211fabddba6d1
EditorCommands implements common edit commands. So, we can use TextEditor even if the instance is HTMLEditor.
Then, EditorCommands can use non-virtual methods of the concrete classes.
MozReview-Commit-ID: DgKHqC0osRb
--HG--
extra : rebase_source : e9abd7ef8b48cfdc65bbeb56ebe81dc0548005dd
nsComposerCommands uses some simple getter methods. They can be simpler non-virtual methods. So, we should do it.
Note that this changes that EditorBase::GetIsSelectionEditable() won't return error. However, it has returned error only when selection controller isn't available. That means that the selection controller has been destroyed and the editor will be destroyed. So, this must not be problem since it returns false (non-editable) instead and won't break any behavior since the editor won't be editable by users nor JS anymore.
MozReview-Commit-ID: E9ccFspG6na
--HG--
extra : rebase_source : bcd1314cb386fcaf175adabfefde5885decd87c0
Compiler may can optimize to call virtual methods at build time if we call them with concrete classes because some of them may have final keyword.
Even if not so, we can optimize some methods with creating non-virtual methods.
MozReview-Commit-ID: K3bRlc0URml
--HG--
extra : rebase_source : 4a76635c7aed29501f71ae74f3f73e2b22ca219e
All SetState() methods in nsComposerCommands require HTMLEditor. So, it should take HTMLEditor* rather than nsIEditor*.
MozReview-Commit-ID: AVbnRsMsmeY
--HG--
extra : rebase_source : 23bcc585a045a39620102c4fef9c1a9e12b9ea37
Similar to GetCurrentState(), all ToggleState() methods require HTMLEditor. So, they should take HTMLEditor* instead of nsIEditor*.
MozReview-Commit-ID: BwM6WRKFn6Q
--HG--
extra : rebase_source : 425b7b405b5881b97e8113c3ab88e9d0514b6a07
All GetCurrentState() methods in nsComposerCommands require HTMLEditor but its argument is nsIEditor*. So, it should take HTMLEditor* and it shouldn't be called if given editor isn't HTMLEditor since it's virtual method.
MozReview-Commit-ID: HsvYJN8hIxN
--HG--
extra : rebase_source : f8f9c8de902af5311771b71a96c76d63325970a5
nsIEditor is still first contact with editor class for some modules. They should be accessible to the concrete classes without QI. Therefore, nsIEditor should have As*Editor() methods.
Additionally, this adds AsEditorBase(). That is always implemented but it might be necessary for some files for minimizing its include files.
MozReview-Commit-ID: 8WqkDJLiVDs
--HG--
extra : rebase_source : e51282df244efad62bc6fe04ab449e3beab440f9
If a range endpoint is in the middle of a text node, and you call
deleteContents() or extractContents(), the spec says to delete the data
from the node. In the case of extractContents(), the new text node
that's inserted into the DocumentFragment is a clone with its data set
to the bit that was deleted.
<https://dom.spec.whatwg.org/#dom-range-deletecontents>
<https://dom.spec.whatwg.org/#dom-range-extractcontents>
We don't do this. Instead, we split the text node. Then the bit to
delete is deleted naturally at a later stage together with all the other
nodes.
The result is the same, but on the way there we do a bunch more node
mutations. This causes extra mutation records, which cause us to fail a
WPT test. Chrome passes. Changing to match the spec actually reduces
our lines of code anyway.
MozReview-Commit-ID: FTTV5yNSj71
--HG--
extra : rebase_source : 8d5f36c68c71db0700f0b86d1a73462759f922e8
When range is selected table element, Selection.addRange uses nsFrameSelection. If frame isn't constructed yet, addRange throws NS_ERROR_FAILURE even if table element isn't editable element.
When getting nsITableCellLayout, we should flush frame to construct cell frame.
MozReview-Commit-ID: 9qWwW46RYNL
--HG--
extra : rebase_source : 708e78af457a28bc273b83015f78950a5bee232e
When recycling chunks, mozjemalloc tries to avoid keeping around more
than 128MB worth of chunks around, but it doesn't actually look at the
size of the chunks that are recycled, so if chunk larger than 128MB is
recycled, it is kept as a whole, going well over the limit.
The chunks are still properly reused, and further recycling doesn't
occur, but that can limit other mmap users from getting enough address
space.
With this change, mozjemalloc now doesn't keep more than 128MB, by
splitting the chunks it recycles if they are too large.
Note this was not a problem on Windows, where chunks larger than 1MB are
never recycled (per CAN_RECYCLE).
--HG--
extra : rebase_source : 6765fd30b78ca5ddc7d55aac861355d960e47828
Despite the comment, this was necessary only for a direct convolver stage,
which has been removed:
https://hg.mozilla.org/mozilla-central/rev/e66105937eef190dec073f1b9859e07a0272706b#l4.29
FFT convolver stages pad the buffer to the necessary length in
FFTBlock::PadAndMakeScaledDFT().
MozReview-Commit-ID: LqP1x1hmLOM
--HG--
extra : rebase_source : 622e16140b62ca748a31cbd318f881c617baf17a
CompositionTransaction forgets to call EndBatchChanges when GetSelectionController returns error, so we should use RAII class instead.
MozReview-Commit-ID: HI9kutRVzx6
--HG--
extra : rebase_source : d276f4349c5a64d4610581ae1a76d160841f7d7b
When recycling chunks, mozjemalloc tries to avoid keeping around more
than 128MB worth of chunks around, but it doesn't actually look at the
size of the chunks that are recycled, so if chunk larger than 128MB is
recycled, it is kept as a whole, going well over the limit.
The chunks are still properly reused, and further recycling doesn't
occur, but that can limit other mmap users from getting enough address
space.
With this change, mozjemalloc now doesn't keep more than 128MB, by
splitting the chunks it recycles if they are too large.
Note this was not a problem on Windows, where chunks larger than 1MB are
never recycled (per CAN_RECYCLE).
--HG--
extra : rebase_source : f81e94c6960ba253037f77de1a39c9ff74651e80
This is an imperfect workaround. Ideally we'd want layout to determine the
correct color here: If the pushed layer will end up on something mostly opaque
in the outer layer, the font smoothing background color should be transparent
(or even a color that approximates that opaque content), and if the pushed
layer will end up on transparency in the outer layer, the appropriate font
smoothing background color for the outer layer should be used when drawing text
in the pushed layer.
This workaround causes us to lose subpixel AA in background tabs that have the
overflow mask applied to them. For those, using the font smoothing background
color in the pushed layer was the right choice.
MozReview-Commit-ID: FPufh04EVp3
--HG--
extra : rebase_source : 7a6cb73255bdb7f1b8aba7df60ebe61171275da4
Shih-Chiang Chien
Ricky Chien
Steve Fink
David Anderson
Eugen Sawin
Paul Adenot
Geoff Brown
Dyex
Mark Banner
Masayuki Nakano
Dale Harvey
Aryeh Gregor
Dão Gottwald
Johann Hofmann
Luke Chang
Emilio Cobos Álvarez
Jan Odvarko
Makoto Kato
Manish Goregaokar
Mike Hommey
Karl Tomlinson
Phil Ringnalda
Xidorn Quan
Markus Stange