The default bug view has changed. See this FAQ.

Cannot use the Geolocation API within the desktop web runtime

VERIFIED FIXED in Firefox 15

Status

Firefox Graveyard
Webapp Runtime
P1
major
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: Mardak)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 15
Dependency tree / graph

Details

(Whiteboard: [blocking-webrtdesktop1+], [qa!])

Attachments

(6 attachments, 3 obsolete attachments)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta-]
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta-] → [marketplace-beta=]
(Assignee)

Comment 1

5 years ago
What should the interface look like? Pre-approved API access? Some in-content-area dialog? A separate panel?
(Reporter)

Comment 2

5 years ago
Jen - Could you clarify? What's acceptable for a first release with geolocation?
(Reporter)

Comment 3

5 years ago
Nominating for k9o, as geolocation is a piece of app functionality used in top apps such google maps.
blocking-kilimanjaro: --- → ?

Updated

5 years ago
blocking-kilimanjaro: ? → +
(Reporter)

Updated

5 years ago
Keywords: productwanted
(Reporter)

Comment 4

5 years ago
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?
(Reporter)

Updated

5 years ago
Whiteboard: [marketplace-beta=]
(Reporter)

Comment 5

5 years ago
Asa - Does https://bugzilla.mozilla.org/show_bug.cgi?id=749459#c32 apply to this bug as well?

Comment 6

5 years ago
(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.
(Reporter)

Updated

5 years ago
Keywords: productwanted
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
(Reporter)

Updated

5 years ago
Target Milestone: --- → M1
(Reporter)

Comment 7

5 years ago
Flagging uiwanted - We need a user interface for this for desktop webrt.
Keywords: uiwanted
(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.
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.
(Reporter)

Comment 10

5 years ago
Jonas - Does comment 9 make sense with the security permissions specified for geolocation?
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.
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
(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?
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
(Reporter)

Updated

5 years ago
Target Milestone: M1 → Firefox 15
Blocks: 746384
Created attachment 627339 [details]
Windows Mock up
(Assignee)

Comment 15

5 years ago
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

5 years ago
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

5 years ago
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

5 years ago
Created attachment 627375 [details]
Mockup for Mac

Mockup for MAc
(Reporter)

Comment 19

5 years ago
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.
Attachment #627339 - Flags: feedback?(jonas)
(Reporter)

Updated

5 years ago
Attachment #627375 - Flags: feedback?(jonas)
(Reporter)

Updated

5 years ago
Keywords: uiwanted
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

5 years ago
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.
Ed: would you be able to tackle this one by any chance?
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.
(Assignee)

Comment 24

5 years ago
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
(Assignee)

Comment 25

5 years ago
(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.
Assignee: nobody → edilee
(Assignee)

Comment 26

5 years ago
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?
(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.
(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.)
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/
(Assignee)

Comment 30

5 years ago
(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?
(Reporter)

Comment 31

5 years ago
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.
in firefox?  i was involved.  beltzner too.  now adays, madhava is probably you're best bet.
(Reporter)

Comment 33

5 years ago
(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?
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.
(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.)
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.
(Assignee)

Comment 37

5 years ago
Created attachment 628125 [details]
wip test dialogs
(Assignee)

Comment 38

5 years ago
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.
Attachment #628125 - Attachment is obsolete: true
(Reporter)

Comment 39

5 years ago
(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/).
Yup. I still think modal is a bad idea, but I can live with it for now.
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!
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.
(Reporter)

Comment 43

5 years ago
Lucas - Could you address the security concern brought up in comment 41 and comment 42?
(Reporter)

Updated

5 years ago
Keywords: privacy-review-needed
(Reporter)

Comment 44

5 years ago
Curtis - Doug Turner suggests we do a privacy review of this feature. Thoughts?
(Assignee)

Comment 45

5 years ago
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.
Attachment #628442 - Flags: review?(myk)
(Assignee)

Comment 46

5 years ago
Created attachment 628443 [details]
screenshot v1
Attachment #628132 - Attachment is obsolete: true
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.
(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

5 years ago
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...
(Assignee)

Comment 50

5 years ago
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 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).
Attachment #628442 - Flags: review?(myk) → review+
(Reporter)

Comment 52

5 years ago
FYI - I have filed bug 760086 for followup UX work to address the feedback brought up on this bug.
(Assignee)

Comment 53

5 years ago
(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.
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.
(Assignee)

Comment 55

5 years ago
Created attachment 628864 [details] [diff] [review]
for checkin
Attachment #628442 - Attachment is obsolete: true
(Assignee)

Comment 56

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9265be2869ca
Blocks: 760086
(Reporter)

Comment 57

5 years ago
Note - Any discussions regarding the feedback for UX, privacy, and other concerns should be taken to the followup bug (bug 760086).
(Reporter)

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [qa+]
https://hg.mozilla.org/mozilla-central/rev/9265be2869ca
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Blocks: 757320
(Reporter)

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa+:jsmith]
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
Keywords: privacy-review-needed
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith)
(Reporter)

Updated

5 years ago
Attachment #627339 - Flags: feedback?(jonas)
(Reporter)

Updated

5 years ago
Attachment #627375 - Flags: feedback?(jonas)
(Reporter)

Comment 60

5 years ago
Verified on Windows 7. Need to also test on OS X to be able to verify this fix.
(Reporter)

Comment 61

5 years ago
(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).
(Reporter)

Comment 62

5 years ago
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.
Status: RESOLVED → VERIFIED
Whiteboard: [blocking-webrtdesktop1+], [qa+:jsmith] → [blocking-webrtdesktop1+], [qa!]
(Reporter)

Updated

5 years ago
QA Contact: desktop-runtime → jsmith
(Reporter)

Updated

5 years ago
Flags: in-moztrap?(jsmith)
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.