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
The search feature in the Late Writes section does not work, and a message claiming "Sorry there's no data available in "Late Writes" hindered the view of the data. I added the late-writes-section to the search blacklist.
MozReview-Commit-ID: 4Fqfh9zhzJZ
--HG--
extra : rebase_source : 35428e159c025b029dd2c7716d679ee1825d5b95
The search feature in the Browser Hangs section does not work, and a message claiming "Sorry there's no data available in "Browser Hangs" hindered the view of the data. I added the chrome-hangs-section to the search blacklist.
MozReview-Commit-ID: JJ4eb1fSOfg
--HG--
extra : rebase_source : 671fa5553516ce4b82ae2893e041839c1af27ae9
Also remove the unmatched candidates in the candidate pair table since
they are now included in the "all raw candidates" table.
MozReview-Commit-ID: 4ZvhWfmjGJh
--HG--
extra : rebase_source : bf999db83cd49dd454434d2b157023da41b0dbcd
- Table headings are now bolded.
- Table captions are supported.
MozReview-Commit-ID: KBs6PLpfaS9
--HG--
extra : rebase_source : dd0b2ffe61559538157eb5bca3b61746db9f5769
See comment 50 for the cause. Since file_silentAudioTrack.html calls play() to
start playback immediately, it is possible that 'mozentervideosuspend' has been
fired before check_video_decoding_state() has a chance to register event handlers.
We call load() and play() to start playback from the beginning so we won't miss
any events.
MozReview-Commit-ID: 9sKygfIxEtS
--HG--
extra : rebase_source : 32b087b808995f771b6fba901f9922af79169af0
extra : intermediate-source : 3fdd51bfa62909066db4813eee4baf0f3caefbdf
extra : source : ad64cd308ce5bb8378d884bf3342c3d8133f144a