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.
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.
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
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
- added an early exit to skip table string comparisons on a 204
- removed an unnecessary NS_WARNING on gethash errors (e.g. 503s)
- do the noise check first since it's the majority of completions
MozReview-Commit-ID: Lqae5DbUrs8
