Last Comment Bug 748214 - Cannot use the Geolocation API within the desktop web runtime
: Cannot use the Geolocation API within the desktop web runtime
Status: VERIFIED FIXED
[blocking-webrtdesktop1+], [qa!]
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: P1 major
: Firefox 15
Assigned To: Ed Lee :Mardak
: Jason Smith [:jsmith]
Mentors:
Depends on:
Blocks: k9o-webrt 757320 760086
  Show dependency treegraph
 
Reported: 2012-04-23 21:14 PDT by Jason Smith [:jsmith]
Modified: 2016-03-21 12:39 PDT (History)
14 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Geolocation WebRT vs. Firefox (353.86 KB, image/png)
2012-04-23 21:14 PDT, Jason Smith [:jsmith]
no flags Details
Windows Mock up (31.32 KB, image/png)
2012-05-25 13:32 PDT, Jennifer Arguello :ticachica
no flags Details
Mockup for Mac (35.40 KB, image/png)
2012-05-25 14:53 PDT, Dils
no flags Details
wip test dialogs (83.30 KB, image/png)
2012-05-29 15:33 PDT, Ed Lee :Mardak
no flags Details
wip test dialogs (305.91 KB, image/png)
2012-05-29 15:59 PDT, Ed Lee :Mardak
no flags Details
v1 (7.08 KB, patch)
2012-05-30 13:28 PDT, Ed Lee :Mardak
myk: review+
Details | Diff | Review
screenshot v1 (46.02 KB, image/png)
2012-05-30 13:29 PDT, Ed Lee :Mardak
no flags Details
screenshot v1 windows (19.49 KB, image/png)
2012-05-30 16:10 PDT, Ed Lee :Mardak
no flags Details
for checkin (6.98 KB, patch)
2012-05-31 12:49 PDT, Ed Lee :Mardak
no flags Details | Diff | Review

Description Jason Smith [:jsmith] 2012-04-23 21:14:13 PDT
Created attachment 617771 [details]
Geolocation WebRT vs. Firefox

If an app decides to make a request to determine the user's location using the geolocation API, typically on a browser, you will see a prompt allowing the user to declare whether they would like to share their location. Sharing their location will then allow the API caller to the geolocation API to determine the user's location.

In the web runtime, this is currently not possible. Accessing a part of the application that requires the geolocation will not give the application any opportunity to utilize geolocation information, as there is no way to grant permission to the application in the desktop runtime to access a user's location. I would expect that an application should be able to use the geolocation API within the desktop web runtime.
Comment 1 Ed Lee :Mardak 2012-04-30 09:47:10 PDT
What should the interface look like? Pre-approved API access? Some in-content-area dialog? A separate panel?
Comment 2 Jason Smith [:jsmith] 2012-04-30 09:48:22 PDT
Jen - Could you clarify? What's acceptable for a first release with geolocation?
Comment 3 Jason Smith [:jsmith] 2012-05-07 21:18:10 PDT
Nominating for k9o, as geolocation is a piece of app functionality used in top apps such google maps.
Comment 4 Jason Smith [:jsmith] 2012-05-10 15:09:19 PDT
Needs assistance from the product management team. Open question - Should we support the geolocation API in the first release of the desktop webRT? If so, how much functionality should we support? What functionality could be supported in a future release?
Comment 5 Jason Smith [:jsmith] 2012-05-10 21:18:26 PDT
Asa - Does https://bugzilla.mozilla.org/show_bug.cgi?id=749459#c32 apply to this bug as well?
Comment 6 Asa Dotzler [:asa] 2012-05-10 21:34:38 PDT
(In reply to Jason Smith [:jsmith] from comment #5)
> Asa - Does https://bugzilla.mozilla.org/show_bug.cgi?id=749459#c32 apply to
> this bug as well?

Yep.
Comment 7 Jason Smith [:jsmith] 2012-05-10 21:41:54 PDT
Flagging uiwanted - We need a user interface for this for desktop webrt.
Comment 8 Jennifer Arguello :ticachica 2012-05-11 10:41:34 PDT
(In reply to Jason Smith [:jsmith] from comment #7)
> Flagging uiwanted - We need a user interface for this for desktop webrt.

UI in desktop uses a doorhanger to prompt the user. We'll probably need to come up with a consistent way of notifying users of these permissions that need a prompt.
Comment 9 Jennifer Arguello :ticachica 2012-05-15 14:43:24 PDT
UX is recommending to use a native prompt with the same copy that is used in the Firefox desktop chrome to grant permission.
See this wiki for App permissions information: https://wiki.mozilla.org/Apps/Security/Permissions


 
UX will add a mock up to show what this flow will look like. 

needs engineering to estimate the work for this.
Comment 10 Jason Smith [:jsmith] 2012-05-15 17:19:07 PDT
Jonas - Does comment 9 make sense with the security permissions specified for geolocation?
Comment 11 Jonas Sicking (:sicking) PTO Until July 5th 2012-05-16 10:33:24 PDT
I'm not sure what "native prompt" means.

We need to do the same thing in WebRT as we are doing in Firefox. I.e. we need to have the XULRunner app display a prompt, ideally very similar to the one used by firefox, where the user is given the same options (share, always share, never share, not now) and the same help link.

What exactly the prompt should look like is up to UX. But please look to firefox what what capabilities we have in the prompt.
Comment 12 [:fabrice] Fabrice Desré 2012-05-16 10:36:39 PDT
And for the record, geolocation uses nsIContentPermissionPrompt as a glue to the UI. It's implemented here in firefox:
http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1551
Comment 13 Jennifer Arguello :ticachica 2012-05-16 11:05:58 PDT
(In reply to Jonas Sicking (:sicking) from comment #11)
> I'm not sure what "native prompt" means.
> 

My bad. I meant the prompt should have a native look and feel, but the copy and functionality should similar to what Firefox does, as Jonas specified.

(In reply to Fabrice Desré [:fabrice] from comment #12)
> And for the record, geolocation uses nsIContentPermissionPrompt as a glue to
> the UI. It's implemented here in firefox:
> http://mxr.mozilla.org/mozilla-central/source/browser/components/
> nsBrowserGlue.js#1551

Thanks this is helpful. I have a feeling we need some engineering help to understand what is feasible on Mac and Windows. Is there someone UX can work with on this?
Comment 14 Jennifer Arguello :ticachica 2012-05-25 13:32:03 PDT
Created attachment 627339 [details]
Windows Mock up
Comment 15 Ed Lee :Mardak 2012-05-25 13:35:26 PDT
Just making sure, the mockup dialog is actually a separate window that can be moved independently from the app? And the user could click back on the app hiding the dialog and potentially alt-tab back to the dialog?
Comment 16 Dils 2012-05-25 13:50:16 PDT
No this style dialog should freeze the application window until the user makes a choice. Same for Mac as well

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx
Comment 17 Dils 2012-05-25 13:50:27 PDT
No this style dialog should freeze the application window until the user makes a choice. Same for Mac as well

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511268.aspx
Comment 18 Dils 2012-05-25 14:53:27 PDT
Created attachment 627375 [details]
Mockup for Mac

Mockup for MAc
Comment 19 Jason Smith [:jsmith] 2012-05-25 14:59:36 PDT
Comment on attachment 627339 [details]
Windows Mock up

Jonas - Could I get your feedback on this? Just want to make sure this aligns with apps permissions model from your perspective.
Comment 20 Jonas Sicking (:sicking) PTO Until July 5th 2012-05-25 16:37:54 PDT
I don't know that we have a reliable source for the publisher information so I'd remove that.

Also, I'd like to avoid using modal dialogs since we don't really need that here. A nice aspect of the UI that we currently have in firefox is that you can just ignore it without making any decision. That makes it collapse into an icon in the URL bar which you can open later if you decide that you do want to share the location information (the API is also structured around not needing immediate feedback).

Finally, would it work to put "share location" into the share-button? That makes it more likely for users to know what they are saying yes to.
Comment 21 Dils 2012-05-25 17:15:26 PDT
I feel very strongly that we need to have modal dialogs which require users to make a decision. I understand why its not modal on Firefox, mainly because you could have several tabs, and therefore several tasks, going on at once. With apps, the user has much more focus on the task at hand.

Here's the problem with the way Firefox does it. If you don't make a decision right away, on say Geolocation, the dialog goes away and its not clear how to get it back. If you're trying to map something, for example, you can't do it until you grant permission. If you lose the dialog, you're in this state of being stuck. 

Here's a quick video that shows the usability issue:

https://vimeo.com/42868905

UX recommendation is to have modal dialogs unless there are a few strong use cases as to why we shouldn't do that.

Also, I should mention that most of the design decisions were made based on the UI standards for Mac and Windows. That's why on the Mac the button says "Share Location" and just "Share" on Windows. Its just a difference in style.
Comment 22 Myk Melez [:myk] [@mykmelez] 2012-05-28 23:20:14 PDT
Ed: would you be able to tackle this one by any chance?
Comment 23 Jonas Sicking (:sicking) PTO Until July 5th 2012-05-29 01:37:11 PDT
I'm very surprised to hear that modal dialogs is considered the UX recommendation unless there are special circumstances. I was under the impression that interrupting the user's work flow and forcing them to make an immediate decision was generally considered a bad thing. And that that's why we have moved away from modal dialogs as much as possible.

But I do agree that the current Firefox location-grant-ui is too easy lose track of.

My understanding was that the current Firefox UI wasn't designed the way it is because of multiple tabs, but rather to stay out of the user's way.

All that said, it's definitely a UX question so I'll leave it up to the UX team to decide.


However we should definitely put "share location" in the yes-button. That is a user-privacy matter since it's important that users understand the actions that they are taking. Privacy should trump platform conventions.
Comment 24 Ed Lee :Mardak 2012-05-29 08:46:40 PDT
Any particular reason why Mac has "Remember" while Windows has "always/never allow" in more options? Why not just have a Remember checkbox with share/don't share buttons?

remember checked + share = always share
remember checked + don't = never share
unchecked + share = share once
unchecked + don't = cancel

Also, are those windows dialogs handled by Gecko/toolkit or are those windows OS dialogs? The Mac one seems like a simple panel like the one used in Firefox 2:

mac: http://blog.codefront.net/wp-content/uploads/2007/09/firefox-2-remember-my-password-dialog.png
win: http://lh6.google.com/gopinathmunisifreddy/R7zK_vZb6tI/AAAAAAAAB5A/zqlmraNM4zU/s400/Firefox%20-%20Remember%20Password%20Option.png
Comment 25 Ed Lee :Mardak 2012-05-29 09:21:01 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #22)
> Ed: would you be able to tackle this one by any chance?
I'll see if I can get the general flow of the dialog implemented with existing toolkit dialogs for the upcoming merge.
Comment 26 Ed Lee :Mardak 2012-05-29 10:49:25 PDT
Should permissions be per app or per domain? Bug 752666 will allow other sites to load in the app, but should granting geolocation api permission to the app on the app origin mean any other pages loaded should also have access?
Comment 27 Myk Melez [:myk] [@mykmelez] 2012-05-29 12:43:35 PDT
(In reply to Edward Lee :Mardak from comment #25)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #22)
> > Ed: would you be able to tackle this one by any chance?
> I'll see if I can get the general flow of the dialog implemented with
> existing toolkit dialogs for the upcoming merge.

Excellent, thanks!


(In reply to Edward Lee :Mardak from comment #26)
> Should permissions be per app or per domain? Bug 752666 will allow other
> sites to load in the app, but should granting geolocation api permission to
> the app on the app origin mean any other pages loaded should also have
> access?

Per-origin.  So other origins should not have access just because the user grants it to the app's origin.
Comment 28 Myk Melez [:myk] [@mykmelez] 2012-05-29 13:06:50 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #27)
> Per-origin.  So other origins should not have access just because the user
> grants it to the app's origin.

(Although if the existing permissions manager uses domains rather than origins, then that is probably sufficient for the purposes of this bug.)
Comment 29 Doug Turner (:dougt) 2012-05-29 13:32:37 PDT
The wording of the dialog may be misleading and it hard to understand.  You should consider dumbing this dialog down and offering a way for the user to get more information about this decisions.  

Instead:


--------------------------------------------------------------------
/----/
| -- |  Would you like to share you location with Evernote?
| -- |
/----/

   More information

   [ ] Remember this decision


 [ Never ]  [ Cancel ] [/ Share Location /]

--------------------------------------------------------------------


The 'More information' text above could link to something like http://www.mozilla.org/en-US/firefox/geolocation/
Comment 30 Ed Lee :Mardak 2012-05-29 14:00:15 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #27)
> Per-origin.  So other origins should not have access just because the user
> grants it to the app's origin.
Should the dialog indicate the origin somehow?

Also, if the user picks "remember my choice," should there be a way to cancel that decision at a later time? Perhaps this as a followup?
Comment 31 Jason Smith [:jsmith] 2012-05-29 14:02:40 PDT
Random question to bring another UX perspective in - Who was the UX designer who came up with the concept and flow of doorhangers for geolocation? Might be interesting to bring their perspective into this discussion.
Comment 32 Doug Turner (:dougt) 2012-05-29 14:21:59 PDT
in firefox?  i was involved.  beltzner too.  now adays, madhava is probably you're best bet.
Comment 33 Jason Smith [:jsmith] 2012-05-29 14:25:09 PDT
(In reply to Doug Turner (:dougt) from comment #32)
> in firefox?  i was involved.  beltzner too.  now adays, madhava is probably
> you're best bet.

Okay. Madhava - Thoughts on the proposed UX for the web runtime for geolocation vs. the current UX for geolocation on firefox? Does it make sense to have differences here (e.g. native prompt vs. doorhanger)? Or would you propose a different idea?
Comment 34 Doug Turner (:dougt) 2012-05-29 14:39:51 PDT
I can tell you this much.  Modal dialogs are a terrible idea.  Especially when the default option is to grant permission.  I have been told there is plenty of literature on this subject that asserts people are tasks-motivated.  That is, if you drop a dialog in their way, they will click it out of the way so that they may continue doing what they were doing.  The doorhanger sucks less because it is fail safe -- if the user doesn't do anything, there is no granting of permission.
Comment 35 Myk Melez [:myk] [@mykmelez] 2012-05-29 14:43:12 PDT
(In reply to Edward Lee :Mardak from comment #30)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #27)
> > Per-origin.  So other origins should not have access just because the user
> > grants it to the app's origin.
> Should the dialog indicate the origin somehow?

This doesn't seem necessary if it's the app's origin requesting the access.  It does seem warranted if it's another origin, though, per bug 741954.


> Also, if the user picks "remember my choice," should there be a way to
> cancel that decision at a later time? Perhaps this as a followup?

Yes, as a followup!


(In reply to Jason Smith [:jsmith] from comment #33)
> Okay. Madhava - Thoughts on the proposed UX for the web runtime for
> geolocation vs. the current UX for geolocation on firefox?

Hey everyone, feedback is welcome, but keep in mind that the perfect will be the enemy of the good if we try to turn over every stone in our quest for the holy grail of geolocation prompts (a triple-mixed metaphor!).

So if an issue with Dils' current design and Mardak's implementation is so serious that it blocks landing an initial version, then we need to fix it in that initial version.  But otherwise, we might address it in a followup rather than the initial version.


(Regarding the native prompt vs. doorhanger issue, I'm pretty sure Dils had a specific reason for that, which probably had to do with there being little to no chrome in a webapp window to hang a doorhanger off of.)
Comment 36 Jennifer Arguello :ticachica 2012-05-29 14:59:38 PDT
FWIW, I want to reiterate that the given platform needs to be considered when looking at the UX. Consistency in an experience is the goal however this may not be in line with the platform capabilities or with what the current mental model of using the platform is. To be more concrete, a user experience of the web may not be a user experience that is seen in native apps such as the ability to go backwards in a flow i.e The back button of the web. This is where a balance needs to be struck between keeping consistency across all platforms at the cost of a platform specific behavior. 

As Myk said, I'm sure we'll find new user experiences as we build out the web apps platform support, but for initial release I'd like to make sure we hit the requirement that an app can use the geo-location API.
Comment 37 Ed Lee :Mardak 2012-05-29 15:33:11 PDT
Created attachment 628125 [details]
wip test dialogs
Comment 38 Ed Lee :Mardak 2012-05-29 15:59:12 PDT
Created attachment 628132 [details]
wip test dialogs

Using the mac text and windows text on each platform with the "[ ]remember" checkbox and share location/don't share buttons.
Comment 39 Jason Smith [:jsmith] 2012-05-29 16:17:39 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #35)
> > Also, if the user picks "remember my choice," should there be a way to
> > cancel that decision at a later time? Perhaps this as a followup?
> 
> Yes, as a followup!
> 

Let's get a bug tracking this as a future followup then.

> 
> (In reply to Jason Smith [:jsmith] from comment #33)
> > Okay. Madhava - Thoughts on the proposed UX for the web runtime for
> > geolocation vs. the current UX for geolocation on firefox?
> 
> Hey everyone, feedback is welcome, but keep in mind that the perfect will be
> the enemy of the good if we try to turn over every stone in our quest for
> the holy grail of geolocation prompts (a triple-mixed metaphor!).
> 
> So if an issue with Dils' current design and Mardak's implementation is so
> serious that it blocks landing an initial version, then we need to fix it in
> that initial version.  But otherwise, we might address it in a followup
> rather than the initial version.

Agreed. The goal of this bug is just to enable geolocation-based functionality to be able to ensure that we aren't blocked for the release. The UX design discussion here I think is valid, but I agree that could be taken care of in a followup that would not block the 1st release of the web runtime. We might want to file a followup bug to track this though (or some follow-up item somewhere?), as there appears to be a lot of debate on the right approach here.

> (Regarding the native prompt vs. doorhanger issue, I'm pretty sure Dils had
> a specific reason for that, which probably had to do with there being little
> to no chrome in a webapp window to hang a doorhanger off of.)

There's other options to consider, but I'll save that discussion for the followup item (I've got a few ideas to throw out there as alternatives).


(In reply to Jennifer Arguello :ticachica from comment #36)
> FWIW, I want to reiterate that the given platform needs to be considered
> when looking at the UX. Consistency in an experience is the goal however
> this may not be in line with the platform capabilities or with what the
> current mental model of using the platform is. To be more concrete, a user
> experience of the web may not be a user experience that is seen in native
> apps such as the ability to go backwards in a flow i.e The back button of
> the web. This is where a balance needs to be struck between keeping
> consistency across all platforms at the cost of a platform specific
> behavior. 

Let's take this UX discussion in a follow-up bug or tracking item, as the UX debate on the right approach probably isn't a blocker for the release. But it might worth to investigate, as the counterarguments presented here do bring in different perspectives.

> 
> As Myk said, I'm sure we'll find new user experiences as we build out the
> web apps platform support, but for initial release I'd like to make sure we
> hit the requirement that an app can use the geo-location API.

Right, agreed the goal here to enable the functionality.

(In reply to Edward Lee :Mardak from comment #38)
> Created attachment 628132 [details]
> wip test dialogs
> 
> Using the mac text and windows text on each platform with the "[ ]remember"
> checkbox and share location/don't share buttons.

Jonas - Ignoring some of the UX considerations (for now, we'll address that in a separate bug), does this align with security model for geolocation?

My opinion - Go for the simpler dialogs (the ones with less information) - the user I don't think would care about the rationale why in immediate sense (the "Application that use location-awareness..."). Might want to reuse the icon firefox uses for geolocation though and reuse the "learn more" piece to hold the rationale why (the rationale learn more points to is http://www.mozilla.org/en-US/firefox/geolocation/).
Comment 40 Jonas Sicking (:sicking) PTO Until July 5th 2012-05-30 01:37:56 PDT
Yup. I still think modal is a bad idea, but I can live with it for now.
Comment 41 Doug Turner (:dougt) 2012-05-30 02:07:00 PDT
Jonas, I don't think it does.

  A model dialog is not fail safe.  People will click through w/ the default option and compromise their location without really understanding what they are doing.

For goodness sakes, if you are stuck using modal dialogs, you must make the default option NOT to share the user location!
Comment 42 Jonas Sicking (:sicking) PTO Until July 5th 2012-05-30 09:52:30 PDT
Yeah, I agree that the modality affects security here.

One option would be to do like you say and make the "don't share" button the default. Which I think also means putting it on the right side since IIRC that's where default buttons usually go and so is the button more likely that the user pushes to just make the dialog go away.

Oh, another thing that's missing from the dialogs is the "more information" link.
Comment 43 Jason Smith [:jsmith] 2012-05-30 12:43:01 PDT
Lucas - Could you address the security concern brought up in comment 41 and comment 42?
Comment 44 Jason Smith [:jsmith] 2012-05-30 12:47:48 PDT
Curtis - Doug Turner suggests we do a privacy review of this feature. Thoughts?
Comment 45 Ed Lee :Mardak 2012-05-30 13:28:44 PDT
Created attachment 628442 [details] [diff] [review]
v1

Using simpler text for now with cancel/don't share as default selection. Will followup bug to create a custom dialog that would allow for custom links, images, etc.
Comment 46 Ed Lee :Mardak 2012-05-30 13:29:17 PDT
Created attachment 628443 [details]
screenshot v1
Comment 47 Jennifer Arguello :ticachica 2012-05-30 13:46:30 PDT
Asked in IRC, but putting in bug. For now we just want to get things done so if Mardak knows doorhanger better go with that for now.  Please let me know so we can finalize this with UX.
Comment 48 Jennifer Arguello :ticachica 2012-05-30 13:54:48 PDT
(In reply to Jennifer Arguello :ticachica from comment #47)
> Asked in IRC, but putting in bug. For now we just want to get things done so
> if Mardak knows doorhanger better go with that for now.  Please let me know
> so we can finalize this with UX.

Disregard this comment.  I misunderstood the screenshot and led me to the wrong conclusion.
Comment 49 Dils 2012-05-30 13:59:38 PDT
Hey guys, 

For Mac the order of the buttons is always (going left to right) Cancel, then OK. On Windows its the opposite, its OK followed by Cancel. Share in this case is the OK, Don't Share is the cancel so lets not move the location of the buttons. Instead lets make sure the default button (highlighted in blue) is Don't Share on both operating systems. 

The last screenshot that Ed uploaded looks good otherwise...
Comment 50 Ed Lee :Mardak 2012-05-30 16:10:05 PDT
Created attachment 628528 [details]
screenshot v1 windows

On windows, there's a slight blue highlight for the default button as well as the focus ring. Hitting enter/space/esc all get rid of the dialog and doesn't share location.
Comment 51 Myk Melez [:myk] [@mykmelez] 2012-05-31 00:52:22 PDT
Comment on attachment 628442 [details] [diff] [review]
v1

Review of attachment 628442 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, the only issues are nits, so r=myk.

::: browser/locales/en-US/webapprt/webapp.properties
@@ +15,5 @@
>  # LOCALIZATION NOTE (hideApplicationCmdMac.label): %S will be replaced with
>  # the name of the webapp.
>  hideApplicationCmdMac.label=Hide %S
> +
> +geolocation.title=%S - Share Location

Nit: this line could use a localization note that explains what the %S will be replaced with.

::: webapprt/ContentPermission.js
@@ +21,5 @@
> +    if (request.type != "geolocation") {
> +      return;
> +    }
> +
> +    // Ignore requests from non-nsIStandardURLs

Nit: it'd be useful for this comment to explain not only *that* we ignore non-nsIStandardURL requests but also *why* we do so.

::: webapprt/components.manifest
@@ +3,5 @@
>  contract @mozilla.org/webapprt/clh;1 {6d69c782-40a3-469b-8bfd-3ee366105a4a} application=webapprt@mozilla.org
>  category command-line-handler x-default @mozilla.org/webapprt/clh;1 application=webapprt@mozilla.org
>  
> +# ContentPermission.js
> +component {07ef5b2e-88fb-47bd-8cec-d3b0bef11ac4} ContentPermission.js application=webapprt@mozilla.org

Note: this doesn't actually need an "application" flag.  The other lines only have them because I forgot to remove them when I moved the runtime into its own directory (at which point the lines in this file stopped potentially applying to Firefox).  However, it's also harmless, so it's ok to leave it in (I plan to file a bug to remove them all).
Comment 52 Jason Smith [:jsmith] 2012-05-31 06:40:21 PDT
FYI - I have filed bug 760086 for followup UX work to address the feedback brought up on this bug.
Comment 53 Ed Lee :Mardak 2012-05-31 08:28:14 PDT
(In reply to Myk Melez [:myk] [@mykmelez] from comment #51)
> Nit: it'd be useful for this comment to explain not only *that* we ignore
> non-nsIStandardURL requests but also *why* we do so.
I actually just grabbed it from nsBrowserGlue:
http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#1530

I assume it's to avoid NS_ERROR_FAILURE exceptions from certain URIs that don't have .host such as about: URIs. We don't show the host, so perhaps we should just remove the check. The only uses of requestingURI is to pass it to nsIPermissionManager which handles nsIURIs fine.
Comment 54 Lucas Adamski [:ladamski] 2012-05-31 11:03:21 PDT
Modal dialog suck.  The goal of all permission security UI has generally been that it should be ignorable by the user, and that it should fail safe when ignored.  Modal with opt-out goes counter to those two principles.  If we must do modal, then yes at minimum it should be opt-in.
Comment 55 Ed Lee :Mardak 2012-05-31 12:49:01 PDT
Created attachment 628864 [details] [diff] [review]
for checkin
Comment 57 Jason Smith [:jsmith] 2012-05-31 14:41:21 PDT
Note - Any discussions regarding the feedback for UX, privacy, and other concerns should be taken to the followup bug (bug 760086).
Comment 58 Ed Morley [:emorley] 2012-06-01 08:13:03 PDT
https://hg.mozilla.org/mozilla-central/rev/9265be2869ca
Comment 59 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-06-04 09:48:06 PDT
discussed with Sid the decision was made to not to a formal review as this appears to be the same as what we have already covered
Comment 60 Jason Smith [:jsmith] 2012-06-10 16:10:17 PDT
Verified on Windows 7. Need to also test on OS X to be able to verify this fix.
Comment 61 Jason Smith [:jsmith] 2012-06-10 16:19:29 PDT
(In reply to Jason Smith [:jsmith] from comment #60)
> Verified on Windows 7. Need to also test on OS X to be able to verify this
> fix.

Also verified on Ubuntu 12 (looks like this works on Linux too).
Comment 62 Jason Smith [:jsmith] 2012-06-12 14:47:38 PDT
Almost works entirely across each major OS, but there's one problem that exists:

If I reinstall the application where I remembered my choice previously, the choice is lost on Windows and Linux

I'll mark this verified for now, as I think that's a separate issue that can be done as a followup - bug 764172.

Note You need to log in before you can comment on or make changes to this bug.