The ProxyMessenger registers a listener whenever the first addon
starts. Although the map does not have any listeners any more at
the end of the test, the listener itself is not removed because
the message-manager-close notification is not sent for them.
So do not count these persistent message managers in the test.
The actual message managers of interest are those associated with
the (closed) tab.
Note: When the test is run in isolation, it may still fail due
to bugzil.la/1293583. See bug for work-around if you want to test.
MozReview-Commit-ID: IiDHhmvQPcv
--HG--
extra : rebase_source : 3a9332d69be31e34bc704de217c823e2a02dd514
Main thing: Making contextMenus implementation webext-oop compatible.
Preparation:
- Add getParentEvent to ChildAPIManager to allow use of remote events.
- Introduce `addon_parent_only` to "allowedContexts" to only generate a
schema API in the main process.
- Do not fill in `null` for missing keys if the schema declares a key as
`"optional": "omit-key-if-missing"`. This is needed for the second
point in the next list.
Drive-by fixes:
- Ensure that the "onclick" handler is erased when a context closes.
- Do not clear the "onclick" handler in `contextMenus.update` if the
onclick key has been omitted (parity with Chrome).
- Remove some unnecessary `Promise.resolve()`
- Add extensive set of tests that check the behavior of the contextMenus
APIs with regards to the onclick attribute in various scenarios.
MozReview-Commit-ID: A5f3AUQzU8T
--HG--
extra : rebase_source : 0464a1aa2387343a6f1d0fcd8fbabfdd1a68b1bb
And remove redundant `Promise.resolve()` because it is the default
for async functions.
setIcon is not supported on Android, so there was no need to change
mobile/android/components/extensions/ext-pageAction.js.
MozReview-Commit-ID: 94ebaJFxLAi
--HG--
extra : rebase_source : 20466181501b264ba33fc8ab61fdf2bed20f9eef
In one of the previous patches, the viewType of popup changed from
"popup" to "tab". As a result it was closed by the `page-shutdown`
event handler in ext-tabs.js. This prevents that from happening.
Also added a test that checks whether the options page type is a tab, to
prevent future regressions.
MozReview-Commit-ID: 3Qcf08PgNqb
--HG--
extra : rebase_source : c4b89d122df52a7280ff5818903cb1d8737fb31c
Drop linting of the .eslintrc.js config files.
Fix some minor errors in the code (missing let/const, undefined vars).
Let eslint know that some files get their globals from other places (typically via xul script tags).
MozReview-Commit-ID: CwxuwPtRUr6
--HG--
rename : browser/components/contextualidentity/test/browser/.eslintrc.js => browser/components/syncedtabs/test/browser/.eslintrc.js
rename : browser/components/contextualidentity/test/browser/.eslintrc.js => browser/extensions/webcompat/test/browser/.eslintrc.js
extra : rebase_source : 9026aac49953d941853022cbab3e33d7d2f2fa21
Inform the user through a drop-down notification, that the installed
libavcodec is not supported (possibly because it is vulnerable) and should
be updated.
MozReview-Commit-ID: J4VSCeTYyO0
--HG--
extra : rebase_source : 89420f2e76727b91a35afafe273838d173063e32
The popuphiding / popuphidden events are fired synchronously when the popup manager
decides we're doing a "rollup" (closing the popups due to "outside" events). In the case
of this bug, the "outside" event is a click on the input element in content.
Here's the kicker though: we handle that popuphidden event and queue a message to content
_before_ the mouse event that caused the roll-up is dispatched to content. This means that
browser-content.js hears that the popup closed due to popuphidden first, sets its internal
state of popupClosed to true, and then the MouseDown on the input field is processed. The
nsFormFillController then queries browser-content's AutoCompletePopup, sees its closed,
and tells the parent to open it again.
This patch adds the norolluponanchor attribute to the panel, which causes us to ignore the
rollup event if it happens to be targeted within the anchor rect. This means that we need
to trust content to tell us to close the autocomplete popup if the input is clicked when
the popup is open (and this is what bug 1183037, which this bug depends on, does).
MozReview-Commit-ID: 4A9qVfTYIUz
--HG--
extra : rebase_source : 113049adfd07b3ddd91b92b5a156d75465e1e8c9
Accessing <browser> in ContentChild does not work when extensions run in
a separate process.
MozReview-Commit-ID: EK0aOYeGaZ5
--HG--
extra : rebase_source : 359cb1f9022b8097d27aa74a30e133c4a7e7c742
browser.test.sendMessage does not have enough time to finish
before tabs.remove since test moved to ChildAPIManager for
extension pages, causing the test to time out.
MozReview-Commit-ID: 1mmGZOi9fzm
--HG--
extra : rebase_source : b0d1310f867040f1f7d14b94a95ba364e3902f88
This is a simple move of ExtensionContext creation logic to
ExtensionChild.
Before the change, ExtensionContext was initialized as follows:
1. (ext-backgroundPage.js) Create background page
2. (Extension.jsm) document-element-inserted observed.
3. (Extension.jsm) new ExtensionContext + unload observer.
After this commit:
1. (ext-backgroundPage.js) Create background page
2. (ext-backgroundPage.js) emit extension-browser-inserted event
3. (Extension.jsm) Pass global to ExtensionContent + unload listener.
4. (ExtensionContent.jsm) document-element-inserted observed.
5. (ExtensionChild.jsm) new ExtensionContext
The next step is to use frame scripts and synchronize state.
MozReview-Commit-ID: K6mPdq7KQ2T
--HG--
extra : rebase_source : c742dfe89646d6717da134c7408aa5a066107c66
"viewType" is more easily searchable and not as ambiguous as "type".
MozReview-Commit-ID: 8sG4qagFCBu
--HG--
extra : rebase_source : 39d76379996e631b9fc33f0c77d565cf302b9df9
E.g. browser.browserAction.enable(...).then(...) now works as expected.
Removed a Promise.resolve() because that is the default.
MozReview-Commit-ID: 4Shxtn0rjYH
--HG--
extra : rebase_source : 2f2516686c7d79094fac5ff1176c1c9310f1abe5
Also, give the ok(true) a more useful message.
MozReview-Commit-ID: 8PwN5yhVTMF
--HG--
extra : rebase_source : 1dd081c8b63d789a81cca29340dfc650fa9d3cdc
In the pageAction and browserAction schemas, several methods are
declared with `"async": true` but without a specified callback in the
`"parameters"` object, so callbacks are not allowed. However, when a
callback is proxied, the `ParentAPIManager` will mirror the call by
passing in an extra callback to the proxied API - and break.
This patch fixes the issue by removing uses of async:true. Also for
consistency between the browserAction and pageAction methods, the
methods that were not declared as async have also been marked as async.
MozReview-Commit-ID: JQqzmTUAotB
--HG--
extra : rebase_source : 62d1cbc4843dd6c792318337158e4311f8df94a4
If a hidden tab is added at the end of a tab bar with enough tabs to show the
scrollbutton-down arrow, it would cause the arrow to highlight incorrectly,
suggesting there an additional tab to find, but in reality there isn't since it
is hidden. This can occur with DevTools Responsive Design Mode which makes use
of hidden tabs.
By skipping `_notifyBackgroundTab` for hidden tabs, we avoid this issue because
we no longer attempt to highlight the arrow.
MozReview-Commit-ID: 2FoJ7UouJCL
--HG--
extra : rebase_source : 3dea801063624580317076624d8de84f99467317
It doesn't seem good to tie ourselves to the Gecko tooltool manifest for
building clang-cl; we want to stick with something we can update on
clang-cl's schedule, not Gecko's.
WindowWatcher allows for either nsIArray or nsISupports array to be passed in
for the arguments param. This converts all internal usage to nsIArray.
MozReview-Commit-ID: DQjtIkobik0
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This one also probably wouldn't cause problems, but getting rid of the CPOW
was so easy, I did so anyway.
MozReview-Commit-ID: IWNwpKF52gI
--HG--
extra : rebase_source : 909cf7fb351f9a7d27e806616e48592f169dae12
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : a8beed043989f6e69e89d17c0db1864c6d7258ac
I have a pull request for these changes upstream:
https://github.com/CLD2Owners/cld2/pull/50
MozReview-Commit-ID: LUqrA4Genv0
--HG--
extra : rebase_source : b00fea7809d0847b8ba6ed16845b93e05163b252
In the failing case, the context menu is basically appearing over <body>
instead of the image. In that case we don't show the 'view image' option
and don't have a URL to use to open the image, which means we try and
do a security check for the load of '', which fails, and we don't get
a new load on which to run the rest of the test.
My guess is this is happening because if the image hasn't loaded yet
by the time we run the code, it takes up no space at all, and a mouse
event at its coordinates only 'hits' the body.
We can avoid that by givin the element width and height.
MozReview-Commit-ID: kU2IoYTqeE
--HG--
extra : rebase_source : f381a33b62bc910f3becf69b4971b56e57c33e5f
This is a one-line fix. about:rights doesn't take query parameters, isn't interactive, and so making it linkable should be fine for uplift.
MozReview-Commit-ID: CQwh6SPLARf
--HG--
extra : rebase_source : 278b97a21a397c2d6f4cc7fc4da29e12ee27adb9
Call tabs.create immediately after the tab is created without delay to
reduce the chance of losing tabs.onUpdated events.
If needed, the tab waiting is done by `executeScript`, etc.
MozReview-Commit-ID: 7A1zH99zafK
--HG--
extra : rebase_source : 56fb363f45040e76a120e6a3de8feaad1575c337
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 8cb5ea82004ad631fe688bafffa9dc9979568679
- no change on default bookmarks for non-nightly builds
- replace firefox bookmarks by this list for Nightly:
- Link to the Firefox Nightly blog (https://blog.nightly.mozilla.org/)
- Link to Bugzilla https://bugzilla.mozilla.org/
- Link to MDN https://developer.mozilla.org/
- Link to Nightly Tester Tools addon https://addons.mozilla.org/en-US/firefox/addon/nightly-tester-tools/
- Link to about:crashes
- Link to Nightly IRC channel on irc.mozilla.org via mibbit
- Link to Planet Mozilla https://planet.mozilla.org/
The default bookmark in the bookmark toolbar which was a tour of Firefox feature is now a link to mozilla.org/contribute
This patch also:
- removes all rdf id references in links which are unused
- moves all the data-uri icons to replacement variables to avoid multiple copy-pastes and make the code easier to read
- removes the invalid mention that the file was automatically generated, it is not the case
- updates the meta charset line for a shorter one using HTML5 syntax
- uses lowercase html
- some of the links have keywords or tags defined
- update tests with specific values to test for the Nightly channel vs other channels
--HG--
extra : rebase_source : 199428b9f58387fce01e28cb4e05ca84ec681cf4
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
--HG--
extra : rebase_source : a5ff906452cca9764eb52e1b54a83d26efa52e94
extra : source : d4c60188e82c85d8d324706961ecc56b09838b4b
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
--HG--
extra : rebase_source : 7ab28e2ebeaf5ac8a9af8e9f79a58aebb61e1793
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
The problem with entering this mode with touch input is that there's no obvious
time to exit the mode. If the user taps on the tab-close button and then lifts
their finger, they might want to close more tabs or they might want to do
something else. For touch/pen, we don't get events like mousemove/mouseout
to distinguish between the two cases. Using a timeout is one possibility but
for now it seems safer to simply not enter that mode when the user is using
touch input to close tabs.
MozReview-Commit-ID: FR0bMmLArQ5
Disabling the Adobe CDM but leaving it visible means that we won't download it
and if a site tries to use it we will prompt the user to enable DRM and only
then download it.
MozReview-Commit-ID: LtEr0NJMiQM
--HG--
extra : rebase_source : b7c6f005fb6173c41af6a583c22473066a47a5eb
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 6e678cc6d23c604d8ed0888d6ceeeb4bf797cb1f
Move to a late beta of 1.12 to work around the llvm-dsymutil
crashes from running `./mach buildsymbols` with the rustc 1.11
output on current m-c. See bug 1301751 for details.
MozReview-Commit-ID: 1gbAGLOxkaO
--HG--
extra : rebase_source : 14ce15d9890a9e052f67bb795de209220179d70e
- no change on default bookmarks for non-nightly builds
- replace firefox bookmarks by this list for Nightly:
- Link to the Firefox Nightly blog (https://blog.nightly.mozilla.org/)
- Link to Bugzilla https://bugzilla.mozilla.org/
- Link to MDN https://developer.mozilla.org/
- Link to Nightly Tester Tools addon https://addons.mozilla.org/en-US/firefox/addon/nightly-tester-tools/
- Link to about:crashes
- Link to Nightly IRC channel on irc.mozilla.org via mibbit
- Link to Planet Mozilla https://planet.mozilla.org/
The default bookmark in the bookmark toolbar which was a tour of Firefox feature is now a link to mozilla.org/contribute
This patch also:
- removes all rdf id references in links which are unused
- moves all the data-uri icons to replacement variables to avoid multiple copy-pastes and make the code easier to read
- removes the invalid mention that the file was automatically generated, it is not the case
- updates the meta charset line for a shorter one using HTML5 syntax
- uses lowercase html
- some of the links have keywords or tags defined
