When storing ms, 32 bit ints can hold 2^32/1000/60/60/24 ~= 49 days. It's quite conceivable that someone would leave a tab in the background for 50 days.
GetSingleLoopTime returns -1 on exceptional cases but we used an unsigned int to hold the return value in AdvanceFrame. So the |loopTime > 0| check would succeed. Fortunately the |delay.ToMilliseconds() > loopTime| check would fail because loopTime was MAX_UNIT32, so we didn't do anything incorrect.
http://hg.mozilla.org/mozilla-central/rev/263980931d1b (bug 890743) changed GetSingleLoopTime from returning 0 (and uint32_t) to -1 (and int32_t) on exceptional cases. But the caller of GetSingleLoopTime wasn't updated.
Each warning message is generated only when getPropertyState() is called.
MozReview-Commit-ID: C03ZSvPv9ff
--HG--
extra : rebase_source : 5932957f8f0b171c7b100b1c22e70513959c819e
Those message will be modified in part 4 (localization).
MozReview-Commit-ID: 6TMUxemVLcu
--HG--
extra : rebase_source : 65ef1879b3e606ae6dc279981b1e995c7b2cd40b
This change ought to make the necessary allocations for many deferred
finalizations smaller, at the cost of some extra space usage and
slightly slower walking over the array.
Writing PopLastN in this way is probably a bit of a micro-optimization,
but at least it comes with tests and some comments for verifying the
goodness of the code.
The scheme in TestSegmentedVectors to use manually-annotated points and
magic numbers corresponding to those annotations works OK for small
numbers of operations. But for testing bulk push and pop, we're going
to be doing many more operations, so let's move to recording explicitly
in code the operations we expect to see, and checking those instead.
I don't know the full history here; roc asked about this exact thing in
bug 534785 when reviewing the creation of nsTextEditorState. The answer
then was "historical reasons" (the original code is hg@1)...maybe to try
and save some space? Regardless, since the only thing we do here is
convert from/to incoming/outgoing nsStrings, which at least sometimes
appear to be causing OOMs, we might as well hold it as an nsString all
the time. This change will ideally eliminate allocations, as we'll be
able to use nsString's buffer sharing underneath the hood.
This change is just a minor tidying; we need to distinguish between
"have a value" and "don't have a value" in nsTextEditorState::GetValue,
but we can do better than heap-allocating the string.
tabpaint measures how long it takes to open a new tab and show its content.
MozReview-Commit-ID: IIVprFdvH1Z
--HG--
extra : rebase_source : dbe899be09b01df5219e7d29b291a6c1455cfe3b
This is necessary in order to be able to open new tabs from the initial
browser window, since the initial browser window needs to have its
BrowserDOMWindow attribute set when it goes remote - and if it fires
before the onLoad handler in browser.js, the BrowserDOMWindow attribute
that's set on the XUL window (which gets copied over to the remote browser),
hasn't been set yet.
MozReview-Commit-ID: AYyFdyoX8g9
--HG--
extra : rebase_source : ca2728e3c059e26eba09e57ee883c8ca1623631e
mContentParent is really just to be used while handling a synchronous
ContentParent::RecvLoadPlugin call when async plugin init turned on.
In any other context, using it will be unsafe.
This patch adds comments and assertions to ensure that this value isn't set
otherwise, and converts the one use of mContentParent outside of async plugin
init to use an alternative mechanism for identifying the content process.
MozReview-Commit-ID: Esgt1kj0MCt
--HG--
extra : rebase_source : 166b913b401582c6948e4b61efc102dc1b9c8d2f
Nils Ohlmeier [:drno]
Luke Wagner
Andrew Swan
Martijn Wargers
Blake Kaplan
Ryan VanderMeulen
Timothy Nikkel
Hiroyuki Ikezoe
Benjamin Bouvier
Morgan Phillips
Nathan Froyd
Bill McCloskey
Jim Mathies
Kartikaya Gupta
Masatoshi Kimura
Dan Gohman
Gabriele Svelto
sakshi
Brian Hackett
Matt Woodrow
Boris Zbarsky
Kit Cambridge
Tooru Fujisawa
Mike Conley
Aaron Klotz
Dustin J. Mitchell
Randall Barker
Felipe Gomes