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
Because browser_aboutdebugging_devtoolstoolbox_shortcuts.js test open/close the
devtools several times, it takes a long time comparing with other tests.
Also, since the win ccov is super slow, this test was timeouted.
Thus, skip the test on win ccov at this moment.
Differential Revision: https://phabricator.services.mozilla.com/D17173
--HG--
extra : moz-landing-system : lando
Nobody uses it from js, and we only thread the value around in layout. Let's
kill all this code.
Differential Revision: https://phabricator.services.mozilla.com/D16999
--HG--
extra : moz-landing-system : lando
The All Downloads view removes and re-adds its richlistbox for performance reasons.
However, after bug 1492326, this causes the richlistitem's .current property to be assigned before its binding is applied.
Since the .current property fires a11y focus events, this means this property is overridden and thus the events never get fired for that item.
To fix this, move a11y focus event firing into richlistbox.currentItem.
Differential Revision: https://phabricator.services.mozilla.com/D16932
--HG--
extra : moz-landing-system : lando
This is a workaround. To properly fix the issue we need to fix both of bug
1516377 and bug 1508177.
Differential Revision: https://phabricator.services.mozilla.com/D17103
--HG--
extra : moz-landing-system : lando
In Bug 1462100 we started casting to void* because mingw doesn't do
automatic conversions like MSVC does. In Bug 1498695 I backed out that
change because I (mistakenly) thought it wasn't necessary for mingw-clang
when in actuality, I simply wasn't hitting the code path due to
SANDBOX_EXPORTS being defined.
Since we want to _not_ define SANDBOX_EXPORTS I need to put the original
patch back in place.
--HG--
extra : amend_source : a26eec746e7881fa88b963c8dd3c1fa900b6a8b6
This patch adds a test case which tests following "Save ... As" options:
* File menu:
- Save Page As
* Context menu in content pages:
- Save Page As
- Save Image As
- Save Video As
- Save Link As
- Save Frame As
* Page Info "Media" Panel:
- Save As
It triggers the save process and checks if the OA of the saving channel
has the correct first party domain.
- Avoid rendering the computed property list is not expanded.
- Avoid rendering the shorthand overridden computed property list if there is
no overridden properties in the computed property list.
Because old-configure is only refreshed when, essentially,
old-configure.in changes, hardcoded (absolute) paths don't necessarily
match the build environment of the current build.
So instead, use an environment variable that we pass from python
configure when invoking old-configure.
Also do dummy changes to old-configure.in so that old-configure is
refreshed at least once to get the environment-based value.
Differential Revision: https://phabricator.services.mozilla.com/D17077
--HG--
extra : moz-landing-system : lando
With the patch above we do find the input element, and try to autocomplete it
normally, which confuses some tests.
Differential Revision: https://phabricator.services.mozilla.com/D17143
--HG--
extra : moz-landing-system : lando
After the changes from bug 1514340 the app is now informed about tracking with
Content:ContentBlockingEvent instead of Content:SecurityChange
Also initialized mLastTracking with unknown as that is the default value
when no tracking event has been received (eg: no tracking elements on the page)
Depends on D16822
Differential Revision: https://phabricator.services.mozilla.com/D16823
onSecurityChange from browser.js will not send information about tracking
anymore to Java (because it doesn't know about that anymore).
onContentBlocking from browser.js will be responsible for this from now on.
is called after onSecurityChange which will have created a SiteIdentity()
for that tab in Java
is informed only about tracking status which it caches to only send updates
downstream to Java. Will not propagate identical events one after the other.
will not fire for websites which do not contains any tracking elements
A Content:ContentBlockingEvent received in Java will update the tracking
property of SiteIdentity and finally update the UI with
ToolbarDisplayLayout#updateSiteIdentity().
Differential Revision: https://phabricator.services.mozilla.com/D16822
