This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
This avoids starting autoscroll on SVG links, and on HTML links that
contain SVG, by sharing the code that browser's ClickHandlerChild uses
to detect links into BrowserUtils, and using that from AutoScrollChild
to determine if the click happened on top of a link. It also adds a
test so we avoid regressing this in future.
When running the test, I noticed an error from ClickHandlerParent
when the browser for which we receive a click has gone away, and
fixed it by adding a nullcheck and early return.
Differential Revision: https://phabricator.services.mozilla.com/D120024
This moves the exception prettifying to the script security manager for all JS
callers, where it is much cheaper and more consistently applied.
Differential Revision: https://phabricator.services.mozilla.com/D101492
This moves the exception prettifying to the script security manager for all JS
callers, where it is much cheaper and more consistently applied.
Differential Revision: https://phabricator.services.mozilla.com/D101492
This moves the exception prettifying to the script security manager for all JS
callers, where it is much cheaper and more consistently applied.
Differential Revision: https://phabricator.services.mozilla.com/D101492
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
Editable elements will no longer get click events for non-primary mouse buttons
since they are being unshipped from the web in favour of auxclick events.
Listen for auxclick as well so middle-click paste still works.
Don't stop propagation after middle-click paste, instead ignore clicks on
contenteditable elements in ClickHandlerChild.
Update test_middle_click_paste.html for the new behaviour.
Also remove the mNoContentDispatch overrides in HTMLInputElement and
HTMLTextAreaElement that were needed for middle-pasting.
Differential Revision: https://phabricator.services.mozilla.com/D26792
--HG--
extra : moz-landing-system : lando
So it is still preventDefault()able once non-primary clicks aren't web visible.
Don't let browser.js' contentAreaClick handle any non-primary clicks.
ClickHandlerChild.jsm handles them first anyway. Can probably rip it out
entirely in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D26791
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
When user middle clicks a link, most users must not expect to expose clipboard
content to the web application. Therefore, we should stop firing paste event
when user click a link with middle button.
This patch makes ClickHandlerChild.handleEvent() prevent multiple action
when it posts middle click event on a link. Note that even if middle click
event is consumed, default event handler will dispatch paste event.
Unfortunately, this is compatible behavior with the other browsers.
Therefore, we cannot change this behavior with calling preventDefault() and
this is the reason why this patch adds Event.preventMultipleActions().
Out of scope of this bug though, if there is an element which looks like a
link but implemented with JS, web apps can steal clipboard content if user
enables middle click event and user just wants to open the link in new tab.
It might be better to stop dispatching paste event in any browsers and request
to change each web apps.
Differential Revision: https://phabricator.services.mozilla.com/D17209
--HG--
extra : moz-landing-system : lando
Gijs Kruitbosch
Iulian Moraru
Emilio Cobos Álvarez
Kris Maglione
Mihai Alexandru Michis
Butkovits Atila
Cosmin Sabou
Neil Deakin
Dorel Luca
Victor Porof
Ehsan Akhgari
Thomas Nguyen
Christoph Kerschbaumer
Ian Moody
Masayuki Nakano
shindli