When background tabs crash, they were being replaced by about:blank tab
hosted in parent process.
Now that there is a mechanism for lazily creating browsers, discarding the
crashed background browser until they are selected is a cheaper operation
(compared to creating about:blank).
Certain test cases were also updated to take into account the new scenario.
MozReview-Commit-ID: AaOivEoTOvU
--HG--
extra : rebase_source : 407ec73ac5ce39906f2e3e0c6f99c8313b544dad
Bug 1369482 originally replaced label with startlabel,hostname,endlabel. This
updates it to replace label with label,hostname,endlabel which should be
backwards compatible.
MozReview-Commit-ID: 3Aj66eaT5ER
--HG--
extra : rebase_source : abf3520015665d772ac2163d593433ac386d877b
That file is only needed for desktop Firefox and when displaying the page source
in a separate window, which is a desktop-only feature as well.
MozReview-Commit-ID: 5wgvoIW12Xn
--HG--
extra : rebase_source : 2decb45b463ae3fe67a881f0f057c459b8199e41
Binding the Preferences object to a "this" object was supposed to enable userChangedValue to access the DeferredTask instance that XPCOMUtils.defineLazyModuleGetter defines on the "this" object.
I thought that worked, because tests passed, but it turned out that no tests are exercising the branch within userChangedValue that references DeferredTask, which is only followed for pref form controls that specify "delayprefsave."
Only font controls specify that attribute, and there weren't any tests for changes to those controls. This patch adds such tests and then changes the way that DeferredTask is lazily retrieved and referenced to ensure it's defined as referenced in userChangedValue.
MozReview-Commit-ID: BPbGp55s9wC
--HG--
extra : rebase_source : 1851f88c6bed6d4315b3383f3756af863b6d6be5
When Escape key is pressed, nsAutoCompleteController needs to restore last
string which was default value of the input or typed by the user. However,
somebody may change the value, e.g., an event listener which handles
Escape key. In this case, nsAutoCompleteController shouldn't restore the
last string.
Unfortunately, when JS sets input value, DOM "input" event won't be fired.
Therefore, nsAutoCompleteController doesn't have a chance to modify
mSearchString in this case. Therefore, nsAutoCompleteController needs to
store expected input string for checking if somebody modified the input value.
For solving this issue, this patch adds a new member, mSetValue which is
modified when the input value is modified by nsAutoCompleteController itself
or mSearchString is modified.
Even with this patch, if user temporarily selects an item of the popup and
JS sets same value as the selected item from JS, nsAutoCompleteController
restores the input value with mSearchString. However, this must be rare
case and I don't have idea to fix this issue with simple patches.
MozReview-Commit-ID: lig8c7xvD7
--HG--
extra : rebase_source : 787dbfb35bc70d27fb09ec93861164e7a5165be3
Refactored a call to ChromeHangs.render() I forgot while fixing the "Show raw stack data" link (Bug 1427484).
MozReview-Commit-ID: 3Ul1wCRhdxG
--HG--
extra : rebase_source : a9cb33d4862947eed80832507a4a315a8ae81f99
Put a table heading to each search section in the about:telemetry homepage.
MozReview-Commit-ID: 7DaFjy6lbcq
--HG--
extra : rebase_source : c8a735989fc120560dc65c2f86adea2594f93b66
This is necessary because sometimes the async tab switcher will instantiate when
there already exists some background tabs that are rendering via print preview. When
that happens, it's important for the state to be set correctly for them so that we
don't accidentally treat them as still loading, and wait (forever) for them to report
having finished loading.
MozReview-Commit-ID: 2dwo5WlXlgJ
--HG--
extra : rebase_source : 4b1e2fb945f1dc4591c56f836a1caa9adeea9eb4
extra : source : 53bb2bc2b67673572dafc3093280fa72973b3d32
The "Show raw stack data" button in the Browser Hangs section produced nothing but removing the "Browser Hangs" section from the about:telemetry navigation menu. I looked at the way the Late Writes section works and patched the Chrome Hangs render calls accordingly.
MozReview-Commit-ID: Gq681oVrg90
--HG--
extra : rebase_source : 97ca47cd9d0997f69cff62b9201e514ab57d713d
