Check if we have permission from the OS to access the camera and microphone after the user has granted access to a site.
If permission is denied at the OS level, but granted to the site within Firefox, return NotFoundError.
Differential Revision: https://phabricator.services.mozilla.com/D5458
--HG--
extra : moz-landing-system : lando
This moves UAWidgetsChild.jsm from browser to toolkit so that
Fennec and Reftest could pick it up.
Differential Revision: https://phabricator.services.mozilla.com/D5085
--HG--
rename : browser/actors/UAWidgetsChild.jsm => toolkit/actors/UAWidgetsChild.jsm
extra : moz-landing-system : lando
This can happen when the message manager is associated to an embedded frame,
like an <iframe mozbrowser>.
Differential Revision: https://phabricator.services.mozilla.com/D7362
--HG--
extra : moz-landing-system : lando
The new method allows extensions to modify menu items in their own
moz-extension:-pages, with the following features:
- All matching extension items are shown in the root menu (instead of
being moved into a submenu), above other menu items, if any.
- The icons for these menu items are customizable.
- Optionally, the default menu items (including those from other
extensions) can be hidden.
Depends on D6621
Differential Revision: https://phabricator.services.mozilla.com/D6622
--HG--
extra : moz-landing-system : lando
If the pref browser.fission.simulate is true, the event dispatcher in ActorManagerChild will not dispatch events to actors that aren't associated with the same window as the event's target.
In addition, when that pref is on, the actors associated with sub-frames will have their content property bound to the correct content window, that might differ from the message manager's window (which is always related to the top level).
Then, in order to write Fission-compatible code, that specific actor will need to be declared with allFrames = true, meaning that it wants to be instantiated for every frame, and not just top-level ones
Differential Revision: https://phabricator.services.mozilla.com/D6358
--HG--
extra : moz-landing-system : lando
This removes subscribe UI and functionality from the main browser window,
the page info window, and from feed previews. It may leave some stray strings
in subscribe.properties/dtd, which will be removed in bug 1477669 when the
preview code goes away completely.
Differential Revision: https://phabricator.services.mozilla.com/D5982
--HG--
extra : moz-landing-system : lando
This removes subscribe UI and functionality from the main browser window,
the page info window, and from feed previews. It may leave some stray strings
in subscribe.properties/dtd, which will be removed in bug 1477669 when the
preview code goes away completely.
Differential Revision: https://phabricator.services.mozilla.com/D5982
--HG--
extra : moz-landing-system : lando
There is a race condition between the time we decide to fetch an icon and the time we actually store that icon, where the original browser currentURI may have changed.
Differential Revision: https://phabricator.services.mozilla.com/D5685
--HG--
extra : moz-landing-system : lando
There is a race condition between the time we decide to fetch an icon and the time we actually store that icon, where the original browser currentURI may have changed.
Differential Revision: https://phabricator.services.mozilla.com/D5685
--HG--
extra : moz-landing-system : lando
Remove the _manifestURI field and handling of the MozApplicationManifest message.
Differential Revision: https://phabricator.services.mozilla.com/D5336
--HG--
extra : moz-landing-system : lando
Most of the ReaderMode.jsm and Readability.js code is only needed when we
actually need to render a document in reader mode, but also winds up loaded
into any process where we ever check if a page is readerable. This winds up
wasting a huge amount of memory (and probably a huge amount of CPU time)
loading code which is almost never used.
This patch splits ReaderMode.jsm into two modules, one for checking
readability, one for actually entering reader mode. It also separates out the
isProbablyReaderable checks from Readability.js, since the overhead of loading
that script before it's needed is unsupportable.
This means we're probably going to need some effort to keep Readerable.jsm and
Readability.js in sync, but the code in question is pretty trivial, so it
shouldn't be too difficult.
Differential Revision: https://phabricator.services.mozilla.com/D3687
--HG--
rename : toolkit/components/reader/Readability.js => toolkit/components/reader/Readability-readerable.js
rename : toolkit/components/reader/ReaderMode.jsm => toolkit/components/reader/Readerable.js
extra : rebase_source : 66712057591ae20dd66234e3dc78fbba90a6914e
extra : amend_source : f908f62f49ea54b9099ddb87d9f2fc11f12d4dee
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
Set the referenced node to that of the containing media element so related
menu items will be shown in the context menu.
MozReview-Commit-ID: 4BKlINHmTSb
--HG--
extra : rebase_source : 1eb1757c693bcdc432b765aac9fbf28f283a492e