Closed
Bug 1203233
Opened 9 years ago
Closed 8 years ago
Can't use geolocation in a WebExtension
Categories
(WebExtensions :: General, defect, P3)
WebExtensions
General
Tracking
(firefox54 fixed)
People
(Reporter: wbamberg, Assigned: mixedpuppy)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: [permissions]triaged)
Attachments
(2 files, 2 obsolete files)
I've attached a simple WebExtension. It just adds a browser action, with a background script like this:
function doIt() {
console.log("I'm running");
navigator.geolocation.getCurrentPosition(function(position) {
console.log(position.coords.latitude, position.coords.longitude);
});
}
chrome.browserAction.onClicked.addListener(doIt);
I've given it the "geolocation" permission. It works fine in Google Chrome, but in Firefox (Nightly, 43.0a1 (2015-09-09)) I get this in the Console:
I'm running my-background.js:3:3
TypeError: browser is null nsBrowserGlue.js:2653:9
Following the link, it looks like it's failing to display a prompt to ask the user for permission to use geolocation.
Aside from this failing, shouldn't "permissions": ["geolocation"] mean the browser doesn't prompt the user? Or do we not support the geolocation permission yet?
We don't support the geolocation permission yet.
Updated•9 years ago
|
Whiteboard: [permissions]
Updated•9 years ago
|
Blocks: webext, webext-android
Priority: -- → P4
Updated•9 years ago
|
Flags: blocking-webextensions+
Updated•9 years ago
|
Whiteboard: [permissions] → [permissions]triaged
Comment 2•9 years ago
|
||
Geolocation does work in a WebExtension... but not in the background script.
In my popup.html file (moz-extension://c5b86449-4457-4a39-a758-958faf23fc72/popup.html), this code works fine: navigator.geolocation.watchPosition(....)
But, it does NOT work when running in the background script.
Comment 3•8 years ago
|
||
Is this made easier now that bug 1197451 has landed, or does that not affect this one?
Updated•8 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: General
Flags: blocking-webextensions-
Priority: P4 → P3
Updated•8 years ago
|
webextensions: --- → ?
Assignee | ||
Comment 5•8 years ago
|
||
This adds support for the geolocation permission, however does not address use of geolocation in background scripts. At least on OSX, there is an additional (os level) dialog that appears asking to provide permission to Firefox itself, which results in an awkward experience using geo from a panel.
I'm figure that there is an additional restriction preventing use in the background page, probably something in here (maybe related to mOwner or CallerType): https://dxr.mozilla.org/mozilla-central/source/dom/geolocation/nsGeolocation.cpp#1208
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → mixedpuppy
Comment hidden (mozreview-request) |
Assignee | ||
Comment 7•8 years ago
|
||
Comment on attachment 8822256 [details] [diff] [review]
geolocation permission
Figured out prior issues, pushed for review
Attachment #8822256 -
Attachment is obsolete: true
Assignee | ||
Updated•8 years ago
|
Attachment #8831387 -
Flags: review?(aswan)
Comment 8•8 years ago
|
||
Comment on attachment 8822256 [details] [diff] [review]
geolocation permission
Review of attachment 8822256 [details] [diff] [review]:
-----------------------------------------------------------------
A few things:
- The original report says that there is an error in the (browser?) console when trying to use geolocation, is that still the case?
- Is it feasible to test this?
- Please add "geolocation" to the valid permission strings in the schema for manifest.json
- Please add a descriptive string for permission prompts when installing extensions that request this permission. Scott can help you with the wording.
- mozreview for subsequent patches please?
::: toolkit/components/extensions/ext-geolocation.js
@@ +1,3 @@
> +"use strict";
> +
> +var {classes: Cc, interfaces: Ci, utils: Cu} = Components;
var -> let (or const even)
@@ +1,5 @@
> +"use strict";
> +
> +var {classes: Cc, interfaces: Ci, utils: Cu} = Components;
> +
> +Cu.import("resource://gre/modules/ExtensionUtils.jsm");
this doesn't appear to be used
@@ +2,5 @@
> +
> +var {classes: Cc, interfaces: Ci, utils: Cu} = Components;
> +
> +Cu.import("resource://gre/modules/ExtensionUtils.jsm");
> +Cu.import("resource://gre/modules/Services.jsm");
make this a lazy import?
Attachment #8822256 -
Flags: review-
Assignee | ||
Comment 9•8 years ago
|
||
aswan: It looks like you reviewed the patch I obsoleted, rather than the one I pushed to reviewboard.
Comment 10•8 years ago
|
||
I have a WebExtension that asks for geolocation. I give it the location, click remember but when it asks again for the permission I need to approve it again. I clicked "Remember this decision" but it does not remember it. Here is a GIF https://imgur.com/a/cYsFP here is the extension: https://my.owndrive.com/index.php/s/0dPjsbp4FiZL8CB/download
Should I report another bug for this or is it covered by this bug?
Also there is a Reddit post on the subject https://www.reddit.com/r/firefox/comments/5qdb8i/got_bored_and_converted_11_chrome_new_tab/dd2jypj/
Comment 11•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109332
A few nits below, the only big missing piece is that this needs a permission string added to browser/locales/en-US/chrome/browser/browser.properties
::: toolkit/components/extensions/ext-geolocation.js:3
(Diff revision 1)
> +"use strict";
> +
> +var {classes: Cc, interfaces: Ci, utils: Cu} = Components;
var -> let
::: toolkit/components/extensions/ext-geolocation.js:5
(Diff revision 1)
> +"use strict";
> +
> +var {classes: Cc, interfaces: Ci, utils: Cu} = Components;
> +
> +Cu.import("resource://gre/modules/Services.jsm");
This can be imported lazily
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:15
(Diff revision 1)
> + let harness = SimpleTest.harnessParameters.testRoot == "chrome" ? "chrome" : "tests";
> + let BASE_URL = "http://mochi.test:8888/" + harness + "/dom/tests/mochitest/geolocation/network_geolocation.sjs";
This is a plain mochitest, how will harness ever be chrome?
If there is some reason to keep this, please use an interpolated string for BASE_URL
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:27
(Diff revision 1)
> + browser.test.assertTrue(true, "success geolocation call");
> + browser.test.sendMessage("geo-ok");
you can just use `.notifyPass()` and `.notifyFail()` here (and switch to `.awaitFinish()` below.
but can you also test that `getCurrentPosition` fails gracefully when an extension does not have the geolocation permission?
Attachment #8831387 -
Flags: review?(aswan) → review+
Comment hidden (mozreview-request) |
Assignee | ||
Comment 13•8 years ago
|
||
mozreview-review-reply |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109332
Fixed, but can you look at it?
Comment 14•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109524
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:27
(Diff revisions 1 - 2)
> ],
> },
> background() {
> navigator.geolocation.getCurrentPosition(() => {
> - browser.test.assertTrue(true, "success geolocation call");
> + browser.test.notifyPass("success geolocation call");
> browser.test.sendMessage("geo-ok");
you can skip the `sendMessage()` here and just call `awaitFinish()` below instead of `awaitMessage()`
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:41
(Diff revisions 1 - 2)
> + yield extension.awaitMessage("geo-ok");
> + yield extension.unload();
> +});
> +
> +add_task(function* test_geolocation_nopermission() {
> + let BASE_URL = "http://mochi.test:8888/tests/dom/tests/mochitest/geolocation/network_geolocation.sjs";
just make this global to the file instead of repeating it in each test? it can also be const
Comment 15•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109526
Whoops, I meant to add, this is looking good but can you ask either florian or johannh to take a glance at the PermissionsUI and SitePermissions bits?
Assignee | ||
Comment 16•8 years ago
|
||
Florian, can you take a look at the changes in PermissionsUI and SitePermissions?
Flags: needinfo?(florian)
Comment 17•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109612
::: browser/modules/PermissionUI.jsm:266
(Diff revision 2)
> // If we're reading and setting permissions, then we need
> // to check to see if we already have a permission setting
> // for this particular principal.
> let {state} = SitePermissions.get(requestingURI,
> this.permissionKey,
> this.browser);
With the check that used to be at the top of the method now moved further down, are you sure this.browser will always be either valid or null here?
::: browser/modules/SitePermissions.jsm:255
(Diff revision 2)
> * The URI to check.
> *
> * @return {boolean} if the URI is supported.
> */
> isSupportedURI(uri) {
> - return uri && (uri.schemeIs("http") || uri.schemeIs("https"));
> + return uri && ["http", "https", "moz-extension"].includes(uri.scheme);
Can you tell me more about why this change is needed/desirable?
Are moz-extension URLs actually supported for all the cases that call this isSupportedURI method?
The comment above says "Checks whether a UI for managing permissions should be exposed", and says we intentionally reject some URIs that nsIPermissionManager can handle.
::: toolkit/components/extensions/ext-geolocation.js:3
(Diff revision 2)
> +"use strict";
> +
> +let {classes: Cc, interfaces: Ci, utils: Cu} = Components;
const (suggested in comment 8) was better.
Comment 18•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109622
I think the main source of Florians questions is that you're modifying two files to work around their original intention. You're editing SitePermissions.jsm because you have an extension and SitePermissions is managing only site permissions. You're not actually interested in any permission UI, so you're changing PermissionUI.jsm to not show a permission UI in your case. :)
And maybe that's ok because the alternative solutions could be much more complex or inefficient, but it definitely doesn't help the maintainability of these modules.
Have you considered looking into the calling code in nsBrowserGlue[0] and completely circumventing the PermissionUI module?
[0] http://searchfox.org/mozilla-central/rev/4e0c5c460318fb9ef7d92b129ac095ce04bc4795/browser/components/nsBrowserGlue.js#2472
::: toolkit/components/extensions/test/mochitest/mochitest-common.ini:42
(Diff revision 2)
> file_permission_xhr.html
> file_teardown_test.js
> return_headers.sjs
> webrequest_worker.js
> !/toolkit/components/passwordmgr/test/authenticate.sjs
> + !/dom/tests/mochitest/geolocation/network_geolocation.sjs
Nit: Since this file is only required in the test you're adding, why not add it only to the test below?
Assignee | ||
Comment 19•8 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #18)
> Comment on attachment 8831387 [details]
> Bug 1203233 implement geolocation permission
>
> https://reviewboard.mozilla.org/r/107956/#review109622
>
> I think the main source of Florians questions is that you're modifying two
> files to work around their original intention.
I disagree. I'm fixing assumptions made in those two modules. These are assumptions made throughout the codebase. One is that only http[s] should be handled in many cases, generally a valid assumption, but WebExtensions changes that. In many cases now we need to have http[s]|moz-extension. The other is that the only valid browser is one in a tabbrowser. This assumption has dogged many projects I've been on.
> You're editing
> SitePermissions.jsm because you have an extension and SitePermissions is
> managing only site permissions.
A web extension page in a tab can use anything the web can. Prompt uses sitepermissions regardless, so without this change, an addon page in a tab will re-request permissions Ad nauseam. With this change SitePermissions works just fine with a web extension. I saw a bug report on it somewhere, so I could split it out, but it is required to support the prompt change
> You're not actually interested in any
> permission UI, so you're changing PermissionUI.jsm to not show a permission
> UI in your case. :)
I'm not changing it to not show UI, it already does that on its own. I'm changing it to handle the result first if the permission is already set before being concerned about whether a browser notification handler is available.
I actually want the prompt to show *when it can* for any permission that an extension may not have.
> And maybe that's ok because the alternative solutions could be much more
> complex or inefficient, but it definitely doesn't help the maintainability
> of these modules.
>
> Have you considered looking into the calling code in nsBrowserGlue[0] and
> completely circumventing the PermissionUI module?
I could do that, it would check global permissions, but calls in webextensions would still have an edge case for failure when using preferences that are not directly supported in the webextensions api.
We'd still need the change in SitePermissions regardless.
Comment 20•8 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #19)
> (In reply to Johann Hofmann [:johannh] from comment #18)
> > Comment on attachment 8831387 [details]
> > Bug 1203233 implement geolocation permission
> >
> > https://reviewboard.mozilla.org/r/107956/#review109622
> >
> > I think the main source of Florians questions is that you're modifying two
> > files to work around their original intention.
>
> I disagree. I'm fixing assumptions made in those two modules. These are
> assumptions made throughout the codebase. One is that only http[s] should
> be handled in many cases, generally a valid assumption, but WebExtensions
> changes that. In many cases now we need to have http[s]|moz-extension. The
> other is that the only valid browser is one in a tabbrowser. This
> assumption has dogged many projects I've been on.
These modules are closely related to things we display in the urlbar. I think it's a valid assumption for these modules that a browser from the tabbrowser is the only one they need to handle.
But you remind me that PopupNotifications.jsm likely still has leftovers from the code paths we added for SocialAPI, that increase the code complexity in that module. We should likely cleanup at some point.
> I actually want the prompt to show *when it can* for any permission that an
> extension may not have.
So I think that's what confused both Johann and myself. If I install an add-on, and it requests permissions upfront on install, I don't expect that add-on to request more permissions later when I use it. Especially as we implemented a special prompt for the case where an updated webextension needs more permissions than the old version.
If something is going to request permissions at run-time, why isn't it just a web page? Can you show or explain a use case where the behavior you suggest is desirable?
Flags: needinfo?(florian)
Assignee | ||
Comment 21•8 years ago
|
||
(In reply to Florian Quèze [:florian] [:flo] from comment #17)
> Comment on attachment 8831387 [details]
> Bug 1203233 implement geolocation permission
>
> https://reviewboard.mozilla.org/r/107956/#review109612
>
> ::: browser/modules/PermissionUI.jsm:266
> (Diff revision 2)
> > // If we're reading and setting permissions, then we need
> > // to check to see if we already have a permission setting
> > // for this particular principal.
> > let {state} = SitePermissions.get(requestingURI,
> > this.permissionKey,
> > this.browser);
>
> With the check that used to be at the top of the method now moved further
> down, are you sure this.browser will always be either valid or null here?
Not entirely sure, however, the check that I moved already made the assumption that browser was never null.
> ::: browser/modules/SitePermissions.jsm:255
> (Diff revision 2)
> > * The URI to check.
> > *
> > * @return {boolean} if the URI is supported.
> > */
> > isSupportedURI(uri) {
> > - return uri && (uri.schemeIs("http") || uri.schemeIs("https"));
> > + return uri && ["http", "https", "moz-extension"].includes(uri.scheme);
>
> Can you tell me more about why this change is needed/desirable?
Web extensions in a tab making any use of an api that produces a permission prompt would re-prompt every time without this.
Assignee | ||
Comment 22•8 years ago
|
||
florian, johannh:
There are two methods that this patch is addressing in making the geolocation permission. It just so happens that fixing the first fixes the second.
1. WebExtensions API supports an explicit permission, such as geolocation, and if an addon includes this permission, the prompt happens during install, and should not happen otherwise.
2. WebExtensions does NOT support a permission via manifest, or an addon does not specify it in the manifest, but a WebExtension page in a tab wants to use it.
Some expectations/requirements/etc:
- A WebExtensions may have pages in the background, a panel, sidebar, or a tab.
- A WebExtension has access to all normal web apis.
- When an addon opens its own page in a tab, the permission prompting should work as it does for any web page.
- Other pages (background/panel/sidebar) should have access to those as well, so long as the permission is already set (I don't want to bother with the rathole to fix UI for those cases, at least not here).
- WebExtensions API provides a permission mechanism for some, but not all permissioned web apis.
To support #1 above, I could just add a permission check in browser glue. It would be a repetitive check, and would only be necessary to avoid the change in PermissionUI.jsm. To support #2 above, I must have the change in SitePermissions.jsm.
Regarding the change in PermissionUI.jsm, I actually think it is a useful change regardless. It makes a response to a permissioned api always happen, whether it is a cancel or success, in the case where it is a browser that does not have the permission notification capability.
Comment 23•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109978
::: browser/modules/SitePermissions.jsm:255
(Diff revision 2)
> * The URI to check.
> *
> * @return {boolean} if the URI is supported.
> */
> isSupportedURI(uri) {
> - return uri && (uri.schemeIs("http") || uri.schemeIs("https"));
> + return uri && ["http", "https", "moz-extension"].includes(uri.scheme);
Have you verified that this change is enough for the permission info to be shown in the control center panel, and on the page info permissions tab? (Page Info calls SitePermissions.isSupportedURI so I would hope that one is fine)
Do you have a test add-on that can be used while testing/reviewing the patch?
::: toolkit/components/extensions/ext-geolocation.js:19
(Diff revision 2)
> +extensions.on("startup", (type, extension) => {
> + if (extension.hasPermission("geolocation") &&
> + Services.perms.testPermission(extension.principal.URI, "geo") == Services.perms.UNKNOWN_ACTION) {
> + Services.perms.add(extension.principal.URI, "geo",
> + Services.perms.ALLOW_ACTION,
> + Services.perms.EXPIRE_NEVER);
It seems this should be EXPIRE_SESSION, if you don't intend to have this permission saved to disk by the permission manager.
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:40
(Diff revision 2)
> + yield extension.startup();
> + yield extension.awaitMessage("geo-ok");
> + yield extension.unload();
> +});
> +
> +add_task(function* test_geolocation_nopermission() {
Should this test include something using an moz-extension URL?
Assignee | ||
Comment 24•8 years ago
|
||
A test addon, you can also open the panel in a tab from the panel.
- issues a request in the background
- issues requests from browserAction
- issues requests from moz-ext in a tab
Attachment #8658839 -
Attachment is obsolete: true
Assignee | ||
Comment 25•8 years ago
|
||
mozreview-review-reply |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review109978
> Have you verified that this change is enough for the permission info to be shown in the control center panel, and on the page info permissions tab? (Page Info calls SitePermissions.isSupportedURI so I would hope that one is fine)
>
> Do you have a test add-on that can be used while testing/reviewing the patch?
Yes. also uploaded a test addon.
> Should this test include something using an moz-extension URL?
That the call is being made in the background script means that it is a moz-ext url.
Comment hidden (mozreview-request) |
Comment 27•8 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #25)
> > Should this test include something using an moz-extension URL?
>
> That the call is being made in the background script means that it is a
> moz-ext url.
Ah, I wasn't clear enough. Comment 22 said the patch is addressing 2 different methods that were broken. I haven't seen in the test something that covers the case where we'll show a prompt attached to the urlbar when a moz-extension page requests location; and I'm afraid that's likely to regress if it's not covered, because people working on permission prompts will never think about testing that by hand when making changes.
Comment hidden (mozreview-request) |
Assignee | ||
Comment 29•8 years ago
|
||
(In reply to Florian Quèze [:florian] [:flo] from comment #27)
> I haven't seen in the test something
> that covers the case where we'll show a prompt attached to the urlbar when a
> moz-extension page requests location; and I'm afraid that's likely to
> regress if it's not covered, because people working on permission prompts
> will never think about testing that by hand when making changes.
Just added a test for that.
Comment 30•8 years ago
|
||
mozreview-review |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review110304
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:62
(Diff revisions 2 - 4)
> + let extension = ExtensionTestUtils.loadExtension({
> + background() {
> + browser.tabs.create({url: "tab.html"});
> + },
> + files: {
> + "tab.html": `<html><head>
nit: backquotes only when there's a variable to replace, normal single quotes are fine here to avoid escaping the double quotes inside the string.
::: toolkit/components/extensions/test/mochitest/test_ext_geolocation.html:90
(Diff revisions 2 - 4)
> + popupNotification.button.click();
> + }, {capture: true, once: true});
> + });
> +
> + yield extension.startup();
> + yield chromeScript.promiseOneMessage("notification-handled");
Is there not a race here? Should we load the chrome script before starting the extension?
Attachment #8831387 -
Flags: review?(florian) → review+
Assignee | ||
Comment 31•8 years ago
|
||
mozreview-review-reply |
Comment on attachment 8831387 [details]
Bug 1203233 implement geolocation permission,
https://reviewboard.mozilla.org/r/107956/#review110304
> nit: backquotes only when there's a variable to replace, normal single quotes are fine here to avoid escaping the double quotes inside the string.
this is pretty consistent with other WE tests where we tend to use multiline strings.
Comment hidden (mozreview-request) |
Comment 33•8 years ago
|
||
Pushed by mixedpuppy@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6dfd1abb7e94
implement geolocation permission, r=aswan,florian
Comment 34•8 years ago
|
||
Backed out for failing test-oop-extensions/test_ext_geolocation.html:
https://hg.mozilla.org/integration/autoland/rev/321c975186a5d1138ac172785a3ada0a36917ee6
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=6dfd1abb7e943267ef499a17037205d109c19122
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=74002148&repo=autoland
[task 2017-02-02T18:27:57.235058Z] 18:27:57 INFO - TEST-START | toolkit/components/extensions/test/mochitest/test-oop-extensions/test_ext_geolocation.html
[task 2017-02-02T18:27:57.900445Z] 18:27:57 INFO - *** WIFI GEO: startup called.
[task 2017-02-02T18:27:59.902584Z] 18:27:59 INFO - *** WIFI GEO: Use request cache:false reason:No cached data
[task 2017-02-02T18:27:59.910661Z] 18:27:59 INFO - *** WIFI GEO: Sending request
[task 2017-02-02T18:27:59.910991Z] 18:27:59 INFO - *** WIFI GEO: sending {}
[task 2017-02-02T18:27:59.941121Z] 18:27:59 INFO - *** WIFI GEO: server returned status: 200 --> {"status":"OK","location":{"lat":37.41857,"lng":-122.08769},"accuracy":42}
[task 2017-02-02T18:28:01.914857Z] 18:28:01 INFO - *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2017-02-02T18:28:03.913678Z] 18:28:03 INFO - *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2017-02-02T18:28:05.922161Z] 18:28:05 INFO - *** WIFI GEO: Use request cache:true reason:New req. is GeoIP.
[task 2017-02-02T18:28:06.756464Z] 18:28:06 INFO - *** WIFI GEO: shutdown called
[task 2017-02-02T18:33:00.912249Z] 18:33:00 INFO - TEST-INFO | started process screentopng
[task 2017-02-02T18:33:01.556004Z] 18:33:01 INFO - TEST-INFO | screentopng: exit 0
[task 2017-02-02T18:33:01.556438Z] 18:33:01 INFO - Buffered messages logged at 18:27:57
[task 2017-02-02T18:33:01.556734Z] 18:33:01 INFO - SpawnTask.js | Entering test test_geolocation_nopermission
[task 2017-02-02T18:33:01.558988Z] 18:33:01 INFO - SpawnTask.js | Leaving test test_geolocation_nopermission
[task 2017-02-02T18:33:01.560931Z] 18:33:01 INFO - SpawnTask.js | Entering test test_geolocation
[task 2017-02-02T18:33:01.562733Z] 18:33:01 INFO - Extension loaded
[task 2017-02-02T18:33:01.564512Z] 18:33:01 INFO - Buffered messages logged at 18:27:59
[task 2017-02-02T18:33:01.566740Z] 18:33:01 INFO - TEST-PASS | toolkit/components/extensions/test/mochitest/test-oop-extensions/test_ext_geolocation.html | success geolocation call
[task 2017-02-02T18:33:01.568837Z] 18:33:01 INFO - SpawnTask.js | Leaving test test_geolocation
[task 2017-02-02T18:33:01.572795Z] 18:33:01 INFO - SpawnTask.js | Entering test test_geolocation_nopermission
[task 2017-02-02T18:33:01.574600Z] 18:33:01 INFO - Buffered messages logged at 18:28:00
[task 2017-02-02T18:33:01.576402Z] 18:33:01 INFO - Extension loaded
[task 2017-02-02T18:33:01.581918Z] 18:33:01 INFO - TEST-PASS | toolkit/components/extensions/test/mochitest/test-oop-extensions/test_ext_geolocation.html | geolocation call [object PositionError]
[task 2017-02-02T18:33:01.583835Z] 18:33:01 INFO - SpawnTask.js | Leaving test test_geolocation_nopermission
[task 2017-02-02T18:33:01.585738Z] 18:33:01 INFO - SpawnTask.js | Entering test test_geolocation_prompt
[task 2017-02-02T18:33:01.587470Z] 18:33:01 INFO - Extension loaded
[task 2017-02-02T18:33:01.589234Z] 18:33:01 INFO - Buffered messages finished
[task 2017-02-02T18:33:01.591356Z] 18:33:01 INFO - TEST-UNEXPECTED-FAIL | toolkit/components/extensions/test/mochitest/test-oop-extensions/test_ext_geolocation.html | Test timed out.
Flags: needinfo?(mixedpuppy)
Assignee | ||
Comment 35•8 years ago
|
||
Assignee | ||
Comment 36•8 years ago
|
||
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 39•8 years ago
|
||
Pushed by mixedpuppy@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/22651b5d537d
implement geolocation permission, r=aswan,florian
Comment 40•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(mixedpuppy)
Comment 41•8 years ago
|
||
Noting that on https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions, it says we don't support geoLocation.
Also clipboardRead, which https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions#Clipboard_access says we do.
Keywords: dev-doc-needed
Reporter | ||
Comment 42•7 years ago
|
||
I've updated the compat data for those permissions: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions#Browser_compatibility
Marking as dev-doc-complete, but please let me know if we need anything else.
Keywords: dev-doc-needed → dev-doc-complete
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•