For setting AltRight key's key value to "AltGraph" if it should work as so,
we need to know if current keyboard layout has AltGr key. Unfortunately,
Windows doesn't provide such information but we retrieve all input characters
from each key when a keyboard layout is loaded. So, when we load a keyboard
layout, we can mark if current keyboard layout has AltGr key with checking
at least one key inputs different character(s) when AltGr key is pressed.
MozReview-Commit-ID: 8GI3phSVTUS
--HG--
extra : rebase_source : f1622615f03740609984da6d216391e23cae6796
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 7a3b71596b4318f517ec4c3ac0180e2aa3b721c7
Consuming the new 'page-visited' notification was fairly trivial,
since it was already brought over to onVisits. There's not much to
say about this other than that I'm a little bit uncertain about
all the hoops we have to jump through to get a JSContext and
GlobalObject from History.cpp (which is discussed in the earlier
commit in the series).
MozReview-Commit-ID: LHaBWSylyLI
--HG--
extra : rebase_source : 148555189f73fb29a48296215e367c406f3f0286
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 7e140df5961c5a01c13b1fd2489905f61c83959f
yaml.load() can lead to arbitrary code execution because it isn't
secure by default and allows special YAML syntax.
While it shouldn't be a problem here, I'm trying to get rid of all
yaml.load() calls so we can add a lint to ban the practice.
Differential Revision: https://phabricator.services.mozilla.com/D1740
--HG--
extra : rebase_source : eed31255da88254cb248b51c5ab917bcae76f1db
extra : histedit_source : 4a681465ec8434e92dc9164a759eb521c10b9e79
yaml.load() isn't safe and can lead to arbitrary code execution for
untrusted input. While probably not an issue here, I'm trying to
rid the tree of all yaml.load() instances so we can add a lint to
ban its usage.
Differential Revision: https://phabricator.services.mozilla.com/D1739
--HG--
extra : rebase_source : 4db69cde270b71335218b40d7b662c170854a6aa
extra : histedit_source : a740d99092c345ec8c6fcdb028498798c103b6a5
yaml.load() is unsafe and can lead to arbitrary code execution via
syntax like `!!python/object/apply:os.system`. yaml.safe_load() is
more reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D1738
--HG--
extra : rebase_source : 597c07b3c1538dc27ad6f46e01cdb7f48755d0bc
extra : histedit_source : 131d570f8ac1ee047487cba54822dbf20abf6681
yaml.load() can evaluate arbitrary Python code via syntax such as
`!!python/object/apply:os.system`. Seriously.
Let's switch taskgraph to yaml.safe_load(), which is reasonable
about limiting magic.
Differential Revision: https://phabricator.services.mozilla.com/D1736
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
* Test helpers for cards
* Refactor the test_add_link test to test in private & non-private window
MozReview-Commit-ID: AeVJOkSwQps
--HG--
extra : rebase_source : 6e8380826bcac87bc408ff75a6a398b5c4f6cafa
* addSampleAddressesAndBasicCard now accepts arrays of addresses and card, but with no args defaults to its original behavior
* addAddressRecord and addCardRecord helpers
* New helpers for each step in the sequence of clicking through to add a new address
MozReview-Commit-ID: Dto5MSekJTV
--HG--
extra : rebase_source : be32c684dba62d051bb119a530437830e41bb128
Re-creating a new demuxer is fine, provided that the SourceBufferResource exists. However, a resource is only created upon receiving an init segment.
The segment following a call to changeType() must be an init segment, will let the demuxer creation occurs there.
Differential Revision: https://phabricator.services.mozilla.com/D1812
Add whitelist rules to allow access to Extensis Universal Type Manager fonts
on 10.11 and earlier OS versions.
MozReview-Commit-ID: 3cPKlC1xCUW
--HG--
extra : rebase_source : 2f8b126cbc7dff2b4d660b6261c1a45d695e09d8
The term "tab actor" was used ambiguously to mean either the "target actor
representing a tab" or "a child actor of the tab target actor" (such as the
console actor). Here we rename the second case to "target-scoped actor".
Differential Revision: https://phabricator.services.mozilla.com/D1760
--HG--
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-01.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-01.js
rename : devtools/client/debugger/test/mochitest/browser_dbg_tabactor-02.js => devtools/client/debugger/test/mochitest/browser_dbg_target-scoped-actor-02.js