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
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
This is consistent with other apps and toolkits (GTK, LibreOffice), and
gives blind people a better experience by providing a consistent
desktop experience, and consistent behavior of the right arrow key
regardless of the first focusable element.
---
layout/xul/nsMenuBarListener.cpp | 2 +-
layout/xul/nsXULPopupManager.cpp | 17 ++++++++++++++++-
toolkit/content/tests/widgets/window_menubar.xul | 14 ++++++++------
3 files changed, 25 insertions(+), 8 deletions(-)
Mouse click or keyboard press are the events which could activate the page and allow
the page to autoplay.
Other events are not.
MozReview-Commit-ID: FjhcBSH0mCX
--HG--
extra : rebase_source : 2984791e3de7fa2c3a1e08877f72a2e2f0f53852
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : 5a1cc56554d1429f3c5af1c8cecaa1d72471ed21
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : b88ccf98bc2a41aac007d79060424eaa2c2aca88
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : 5d6633a2e1a456d2d619b6f68498065d94c68c40
This patch implements HTMLMediaElement::GetEventTargetParent and set
aVisitor.mCanHandle to false to mouse/touch/pointer events, when
the media control is present. This tells the event dispatcher that
these events are supposed to be handled exclusively by the
videocontrol binding within the media element, and should not
dispatch nor consumed by the content.
MozReview-Commit-ID: BXWZX9SYsuC
--HG--
extra : rebase_source : e9922ac6064c953ee233d6829e84bc7828518b43
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : fb7af066adfa0491a79fae6282a62b08661553c8
Also, use |run-if| instead of |skip-if| to filter the test.
MozReview-Commit-ID: 5NUoSoRzqMC
--HG--
extra : rebase_source : c50eb0cf377d02456089382108a49658ea6930b7
Add a new file "almostSilentAudioTrack.webm" and the test to prevent showing
the sound indicator when playing that kinds of video.
MozReview-Commit-ID: CeUhAePBuqs
--HG--
extra : rebase_source : c1deb2ec749fcebeccb554b64ffe77b46a18aa3d
This mechanically replaces nsILocalFile with nsIFile in
*.js, *.jsm, *.sjs, *.html, *.xul, *.xml, and *.py.
MozReview-Commit-ID: 4ecl3RZhOwC
--HG--
extra : rebase_source : 412880ea27766118c38498d021331a3df6bccc70
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
--HG--
extra : rebase_source : effd7fab536294de967661be4dcaaadc5b869db7
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
* Re-enable cosmeticAnimations pref for browser_ext_popup_select.js which is known to be more reliable with animations
MozReview-Commit-ID: IvA2ySPPmeJ
--HG--
extra : rebase_source : 577f534d2409da76eecd6c36dfa3db50eca50f40
* Toggle animate=false attribute on arrow panels when toolkit.cosmeticAnimations.enabled is false
* Use preferences-service component to lookup the pref in the arrowpanel binding
* Disable this pref during tests to remove a source of instability and timing-based test failures in chrome/UI tests.
* Enable cosmeticAnimations for tests which depend on existing behavior
MozReview-Commit-ID: IvA2ySPPmeJ
--HG--
extra : rebase_source : 4ed74175107b2cf831b698361f0a2a9b1bd72113
Unlike video element, audio has no status overlay to inform users if an
error occurred. Instead of hiding entire media controls, we should keep
it visible in order not confuse users, and see if we can come up with a
better approach such as making the buttons disabled afterwards.
MozReview-Commit-ID: 8YSCxbWwg2O
--HG--
extra : rebase_source : 0da6ce16fe28c7f1d0cbafe0c518f5c2c273abf1
The intermittent failure is caused by the innate drawback of the present test,
it doesn't be consistent with the behavior how we actually block the media.
Since we always block media implicit, it would be set in nsGlobalWindow's ctor.
We would never call blockMedia directly, so we can remove the function.
MozReview-Commit-ID: IjYJi5OHQ3X
--HG--
extra : rebase_source : 1cb5eaf76f237f2c8be430ef94f7d8aa6031cf17
When the block stauts of the window was changed, we would notify front-end side
to update the vaule, so that we can save it for session restore.
MozReview-Commit-ID: FyclKmAxZHf
--HG--
extra : rebase_source : 5ac8bb9d82279074939caed53dd79c072a5097bc
The "blocked" attribute is too general to indicate the real usage, so rename it
to "activemedia-blocked".
This attribute indicates that whether the tab has blocked the autoplay media.
MozReview-Commit-ID: 58U7DJSMtss
--HG--
extra : rebase_source : 762bfd2be06e21a964fd93076867b4f72a085adc
Enable toolkit/content/tests/chrome/test_panel_anchoradjust.xul on linux machines as it no longer permanently fails when running on Ubuntu 16.04.
MozReview-Commit-ID: FOW9zgKYcAU
--HG--
extra : rebase_source : f7667b92e02b34df744fae261534be9f5d50cde3
This patch decreases the assertion counts for toolkit/content/tests/chrome/test_bug437844.xul and layout/xul/test/test_bug393970.xul. It does so by preventing a loop in nsSprocketLayout.cpp from performing one extra pass after hitting the assertion. It also increases the maximum of the expected range for test_bug437844.xul to 34.
MozReview-Commit-ID: 3QVE2LY2sRa
--HG--
extra : rebase_source : de0c33067bb45770708c56b937fa2f4e6a6a3ce0
Disable toolkit/content/tests/widgets/test_popupanchor.xul on linux machines as it permanently fais when running with Ubuntu 16.04.
MozReview-Commit-ID: HSX6xC8dG8k
--HG--
extra : rebase_source : c270b3456c92da2b49daa30cf44308b6880f5ea9
Disable toolkit/content/tests/chrome/test_panel_anchoradjust.xul on linux machines as it permanently fails when running on Ubuntu 16.04.
MozReview-Commit-ID: FOW9zgKYcAU
--HG--
extra : rebase_source : a590ff1dec5abd04ac97efcf03e4bcd61612626a
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : b6573f8e2001f91d0e5a50f6376b191459549e94
extra : intermediate-source : 0411e687044ecc7b56684196238e6e6e68a9d685
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
This patch removes the C++ code used to run the minidump analyzer when a
content process crashes, and replaces it with JS code within the CrashService
object. This removes the need for a separate shutdown blocker in C++ code and
allows end-to-end testing of the crash service functionality. Additionally
the exception handler code can be simplified since it's now only used to run
the crash reporter client.
The test added to test_crash_service.js covers computing the minidump SHA256
hash (bug 1322611) and of the minidump analyzer itself (bug 1280477).
MozReview-Commit-ID: LO5w839NHev
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
randomly firing a 'pause' event when the test isn't expecting it. r=jaws
MozReview-Commit-ID: 65NrpKbIxi7
--HG--
extra : rebase_source : 7e1ec55d5c23b8c0cfa49ca5298d77fef77a2e4b
The "blocked" attribute is too general to indicate the real usage, so rename it
to "activemedia-blocked".
This attribute indicates that whether the tab has blocked the autoplay media.
MozReview-Commit-ID: EAmq6OuBYjq
--HG--
extra : rebase_source : e8e9321854b80736f0959fbfecbc8bf9a83b0712
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : a8553684f8f106c1dfb6e2d9b51df7ebeb15275d
CLOSED TREE
Backed out changeset 941e0f9ff9a7 (bug 1351074)
Backed out changeset 4fdf3b87a70b (bug 1351074)
Backed out changeset 586428f69838 (bug 1351074)
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : 2143fcdf33c428c82c6b2e00b542649b958aeccc
Add new tests and move some share codes to head.js.
MozReview-Commit-ID: GcCio6JupZu
--HG--
extra : rebase_source : a9324aaebd89412d77bed19b0554e6cf2959b6e2
We could not avoid controls being focused after De-XUL, in order
to preventDefault before event propagate to focused control, we should
change the way of keypress event propagation in media controls.
MozReview-Commit-ID: 4KNPU4XlSDJ
--HG--
extra : rebase_source : 1146e18e3beebca8ae36a4de126c5c920aa5cdfd
The test cases should be ordered according to their alphabet order.
MozReview-Commit-ID: LmmyjcTf6Nd
--HG--
extra : rebase_source : 2a0d826cf06ae4ff16f2f8ed5fcb2012ba1dd0a6
Add tests for non-in-tree media element, web-audio and plug-in.
MozReview-Commit-ID: 2BMzUHPjKWX
--HG--
extra : rebase_source : 1005cc83973fdbd33efb0146d9ff87d52659f090
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
--HG--
extra : rebase_source : 61d2aa91bf9474af3d72a5dea41b25dca442c1b7
The test cases should be ordered according to their alphabet order.
MozReview-Commit-ID: LmmyjcTf6Nd
--HG--
extra : rebase_source : e93da9fd41f312c6ce2bc59698597286e6dfc088
Add tests for non-in-tree media element, web-audio and plug-in.
MozReview-Commit-ID: 2BMzUHPjKWX
--HG--
extra : rebase_source : 93c836edb04dbb5cb8cb487e1d5face6ddefdd42
Block-stop should be dispatched before audio-playback, so we can check block
event first. Also add "loop" attribute for video to avoid getting the wrong
pause state.
MozReview-Commit-ID: 3WHuJGsZCPn
--HG--
extra : rebase_source : 75147657a727bf34aacf9feb1674ccf29142a0eb
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
--HG--
extra : rebase_source : ad2985bd14d6a9b91a73c0d4103aa51c4981124c
Tim Nguyen
Alastor Wu
Cameron McCormack
Masayuki Nakano
Myk Melez
Sebastian Hengst
Gijs Kruitbosch
Kartikaya Gupta
JW Wang
Tooru Fujisawa
Dorel Luca
Colomban Wendling
Bill McCloskey
Neil Deakin
Bogdan Tara
Andreea Pavel
Ryan VanderMeulen
Brian Grinstead
Andrea Marchesini
Alphan Chen
Ed Lee
Samael Wang
Cosmin Sabou
Joel Maher
Mark Banner
Noemi Erli
Dan Banner
Timothy Guan-tin Chien
Gurzau Raul
Ray Lin
Nicholas Nethercote
Narcis Beleuzu
Xidorn Quan
Stephen A Pohl
Scott Wu
Amy Chung
Philipp Sackl
John Lin
Botond Ballo
Yoshi Huang
Stone Shih
Andrew Halberstadt
Phil Ringnalda
Emilio Cobos Álvarez
Masatoshi Kimura
Rajesh Kathiriya
Wes Kocher
Carsten "Tomcat" Book
J. Ryan Stinnett
Dão Gottwald
Sam Foster
Christoph Kerschbaumer
Johann Hofmann
Florian Quèze
Nathan Froyd
Greg Mierzwinski
Paolo Amadini
Blake Kaplan
Andrew McCreight
Gabriele Svelto
Shing Lyu
Mats Palmgren
Marco Castelluccio
Makoto Kato
Iris Hsiao
Jared Wein
Jim Porter
Michael Layzell
Mike de Boer
Jonathan Kew
Boris Zbarsky
Geoff Brown
Mike Conley