Bug 1284835 removed the hard-coded learn more link on cert and net error pages, which worked
for cert error pages because they explicitly set their own learn more links, but net error
pages were relying on the default href to be set. This wasn't revealed until bug 1530348
made about:neterror part of the new error pages.
The solution is simply to explicitly set the correct learn more link to net error pages.
Note that in the case of PR_END_OF_FILE errors, we were not previously showing a "learn more"
link. That was not intentional, as far as I can tell, but was caused by the bug fixed in bug 1477875.
Differential Revision: https://phabricator.services.mozilla.com/D35163
--HG--
extra : moz-landing-system : lando
This workaround hands the top-level browser to nsContextMenu rather than the
mozbrowser in the RDM case. We need to do that since RDM does a lot of work
to make the inner mozbrowser _seem_ like the top-level browser, including
proxying messages from that top-most browser to the underlying mozbrowser.
This workaround makes us consistent with that model, and will have to do until
we can get bug 1559456 fixed.
Depends on D35077
Differential Revision: https://phabricator.services.mozilla.com/D35078
--HG--
extra : moz-landing-system : lando
In the content process case, preventing default stops the context menu event from being dispatched
within remote iframes, which is what causes bug 1558506.
In the parent process case, preventing default stops the nsXULPopupListener from opening the context
menu for us when we don't want ContextMenuParent to handle it, which we don't want to do.
Differential Revision: https://phabricator.services.mozilla.com/D35077
--HG--
extra : moz-landing-system : lando
This fixes Bug 1558506 by making it so that the parent process ignores the context menu event
when right-clicking on the remote <browser> hosting the Add-on Options page. Before, we were
handling the event, stopping it from propagating and preventDefault'ing it, and then sending
a message to the parent that ultimately did nothing (since we knew that we didn't want to
display the context menu). Stopping propagation and preventDefault'ing meant that the event
was never fired in the Extension process for the options page.
With the parent process now returning early in the event that it knows that it doesn't want
to be the one to open the context menu, the underlying ContextMenuSpecialProcessChild can
handle the contextmenu event in the extension process, and do the right thing.
Differential Revision: https://phabricator.services.mozilla.com/D34901
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
This introduces a new toolkit module, ContentDOMReference, which can generate identifiers
for DOM elements that can be safely passed across the process boundary without having to
use the CPOW infrastructure.
The Password Manager code seemed to be the only thing using the original CPOW, so this
has been updated to use the ContentDOMReference identifier instead.
Differential Revision: https://phabricator.services.mozilla.com/D32758
--HG--
extra : moz-landing-system : lando
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
We were using the same ID on two elements, which kind of messed up things everywhere
our code reasonably expected only one element of the kind to exist. We just use a
class name now.
This also cleans up #advancedPanelErrorTryAgain which worked around this issue
by using a different ID.
Differential Revision: https://phabricator.services.mozilla.com/D30298
--HG--
rename : browser/base/content/test/general/browser_bug435325.js => browser/base/content/test/about/browser_bug435325.js
extra : moz-landing-system : lando
Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
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
The larger changesets in this patch are simply moving code from one file into the other with hg mv.
A short summary of the changes:
- I removed the forked redirection from AboutRedirector.cpp
- I deleted the original aboutNetError.xhtml and aboutNetError.css files
and moved aboutNetError-new.xhtml and aboutNetError-new.css in their place instead.
- I removed the browser.security.newcerterrorpage.enabled pref and all its usages.
- I removed some localization strings and resources that went unused because of the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D25232
--HG--
extra : moz-landing-system : lando
