This patch ressurects HiddenFrame.jsm and uses it when handling
the --screenshot command line argument to load the requested page
in a content process. The actual logic for grabbing the image is
also ported to a JSWindowActor. The test for this feature remains
suboptimal as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D40148
--HG--
rename : browser/components/shell/HeadlessShell.jsm => browser/components/shell/ScreenshotChild.jsm
extra : moz-landing-system : lando
All built-in engines have migrated from OpenSearch to WebExtensions.
WebExtensions do not support resource: or chrome:-URLs in their
`favicon_url` field, so the "resource:" and "chrome:" URLs can only be
used by external opensearch XML files. These should not rely on internal
resources from omni.ja, as the bug shows. So just drop support for
"chrome:" and "resource:"-URLs, as we don't need them any more.
Current OpenSearch engines that relied on chrome/resource:-URLs can
either replace the URL with a data:-URL, or migrate to WebExtensions.
Differential Revision: https://phabricator.services.mozilla.com/D40345
--HG--
extra : moz-landing-system : lando
This patch ressurects HiddenFrame.jsm and uses it when handling
the --screenshot command line argument to load the requested page
in a content process. The actual logic for grabbing the image is
also ported to a JSWindowActor. The test for this feature remains
suboptimal as described in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D40148
--HG--
rename : browser/components/shell/HeadlessShell.jsm => browser/components/shell/ScreenshotChild.jsm
extra : moz-landing-system : lando
The security UI receives an about:blank load when navigating to or from
about: pages, which causes it to try and render security indicators before
showing the "real" security indicators for the next site. It shouldn't do that.
The solution is a bit cheap, we simply ignore all about:blank and other loads
that will receive a pageproxystate="invalid" state in the URL bar and thus
hide the identity block. This takes care of our problem and also avoids
some work when loading the home page.
Differential Revision: https://phabricator.services.mozilla.com/D40515
--HG--
extra : moz-landing-system : lando
The security UI receives an about:blank load when navigating to or from
about: pages, which causes it to try and render security indicators before
showing the "real" security indicators for the next site. It shouldn't do that.
The solution is a bit cheap, we simply ignore all about:blank and other loads
that will receive a pageproxystate="invalid" state in the URL bar and thus
hide the identity block. This takes care of our problem and also avoids
some work when loading the home page.
Differential Revision: https://phabricator.services.mozilla.com/D40515
--HG--
extra : moz-landing-system : lando
JSTerm `execute` function is renamed to `_execute` to emphasize
that it's a private function.
A `dispatchEvaluateExpression` is added to the WebConsoleWrapper
so other panels can use that if they need to.
A test helper is added to be able to evaluate without grabbing
the jsterm reference, and tests are modified to use the new
helper, or the existing `executeAndWaitForMessage`.
Differential Revision: https://phabricator.services.mozilla.com/D39024
--HG--
extra : moz-landing-system : lando
`UrlbarResult` objects for search results have a `payload.engine` property, the name of the engine, but extensions won't always know the name Firefox uses internally or even any name at all. For example, the top sites API returns search results with aliases but not names. We should let extensions specify engine URLs and aliases, and we can use them to look up the engine name.
The UrlbarResult.jsm change is unrelated but fixes a minor annoyance I found while working on the top-sites extension. My background script returns results with `isKeywordOffer: true`, but that causes an error in `UrlbarResult.payloadAndSimpleHighlights` because it converts string values to arrays and then expects non-string values to be arrays. Instead, it should be converting non-array values to arrays.
Differential Revision: https://phabricator.services.mozilla.com/D39800
--HG--
extra : moz-landing-system : lando
This is based on D39589, which moves the top sites API from toolkit to browser.
* Add a `newtab` option to `browser.urlbar.topSites.get` (similar to the abandoned D36200) that returns exactly the top sites shown on newtab
* Add a `AboutNewTab.getTopSites` function that returns those sites from activity stream
* Keep the changes made in bug 1547669
There are a couple of missing things related to the default top sites that this doesn't address but ideally we would have. I think we can come back to these if necessary.
* Actual favicons for the default top sites instead of using the bigger tile images since they don't seem to be the same for every site.
* Proper names names for the default sites. There's a `hostname` property, but it would be nice to have e.g. "YouTube" instead of "youtube".
Differential Revision: https://phabricator.services.mozilla.com/D39591
--HG--
extra : moz-landing-system : lando
Bug 1547669 added some things to the top sites API, but it turned out to be not quite what we (the quantumbar team) needed (see bug 1568617). What we need is the list of top sites exactly as it appears on newtab. That list is determined by activity stream, which lives in browser. But the top sites API lives in toolkit.
There was an earlier, now abandoned revision for that bug [1] where it was suggested that top sites be moved to browser. So we should do that.
[1] https://phabricator.services.mozilla.com/D36200
Differential Revision: https://phabricator.services.mozilla.com/D39589
--HG--
rename : toolkit/components/extensions/parent/ext-topSites.js => browser/components/extensions/parent/ext-topSites.js
rename : toolkit/components/extensions/schemas/top_sites.json => browser/components/extensions/schemas/top_sites.json
rename : toolkit/components/extensions/test/xpcshell/test_ext_topSites.js => browser/components/extensions/test/xpcshell/test_ext_topSites.js
extra : moz-landing-system : lando
This implements the idea of automatically setting a content proc's
render root based on the render root enclosing the iframe that
points to it. There was a bit of cleanup in here that was a bit
tricky to extract from the core patch revolving around how we
use the Api(...) helper. This was to avoid the situation where
we use the Api(...) helper before our render root is initialized,
when we don't actually have to. I.e., when we just want the root
WebRenderAPI in all cases.
An alternative to this approach could be to fully built out the
WebRender transactions and just queue those up to be sent. However,
transaction building has various side effects which are committed
before the transaction is actually sent, so we would have to build
out some scheme for deferring those as well. This seemed simpler.
Patch primarily written by :dthayer
Differential Revision: https://phabricator.services.mozilla.com/D37078
--HG--
extra : moz-landing-system : lando
