Paul Theriault [:pauljt] (no longer reading bugmail) Reporter
	Description • 10 years ago

So in the current nightly build, and for a while, it has been very difficult to figure out what web page you are visiting in the system browser. The rocketbar shows the title of the page usually, and to actually see the URL, you have to tap the rocketbar, then tap and drag in a very precise way to see the left hand end of the URL.

Its hard enough to get users to check the URL and SSL state, and maybe the URL more hidden only increasing the risk of phishing and other related security issues. 

I know the rocketbar is in a state of flux, so I hesitated filing a bug, but I am worried that even the rocketbar spec doesn't outline a clear way for the user to know what the URL of the current page is. (or more importantly the domain, the actual page isn't as important)

I'm mainly filing this bug just to make sure this doesn't fall between the cracks, and find out what plans (if any) there are to address the current state.

	Kevin Grandon :kgrandon
	Comment 1 • 10 years ago

Thanks for filing, I don't think we have anything specifically filed that tracks this, and what's currently in 2.1 is what we were planning on shipping.

There was a bug where we were considering showing the origin instead of title in the rocketbar, but that wasn't very useful when browsing for a variety of reasons, so we went with the title instead. Some options of what we can do:

1 - Leave it as is, and find ways to mitigate this with work elsewhere. Seems we may have lost the URL in the task manager, but maybe we could bring that back.
2 - Show the entire URL instead of the title.
3 - Show the origin or URL in addition to the title. E.g., mozilla.org | Home of the Mozilla...

	Frederik Braun [:freddy]
	Comment 3 • 10 years ago

Summarizing what Ben Francis said in the dev-gaia mailing list (https://groups.google.com/forum/#!msg/mozilla.dev.gaia/FOGRAuFNoYc/d6rw5jmT8r0J) and what other cases we might have.

We have several means we currently indicate something:
- The RocketBar is smallish in most apps and full-width
- The task switcher shows an icon as well as an app-title. The window switcher for the browser window does something very similar. It is notable that a screenshot of a browser app shows the title in *both* the rocketbar as well as the task switcher.
- In the browser: the rocket bar shows the title. When tapped, it shows the current URL.
- A dialog (regardless of app window or within the browser) may be handled differently for same-origin and cross-origin dialogs. Currently both cases show the title (with a lock, if applicable) and there is *no* way to show the current URL. It may have been spoofed. The lock on a spoofed HTTPS website may give a false sense of security.


I think it could make sense to show the URL (or at least the origin) as a headline over the open windows. The icon as well as the rocket bar are showing the title anyway.
That leaves us with dialogs: The dialog-title is immutable. There is no way to see where the current site is located. I could imagine having this behave like the rocket bar: Tap the title to see and possibly modify the URL.

The spoofing risk the rocket bar currently bears is still unaddressed: Anyone may set up a spoofed login website over HTTPS with a real-looking title.


Does this make sense? Did I leave a use case out?
We want to work with the existing plans (and UX specs) to make sure these things are addressed.

	Kevin Grandon :kgrandon
	Comment 4 • 10 years ago

(In reply to Frederik Braun [:freddyb] from comment #3)
> I think it could make sense to show the URL (or at least the origin) as a
> headline over the open windows. The icon as well as the rocket bar are
> showing the title anyway.

I agree. It seems we could either replace the title in the task manager, or add a new line with the origin/url.


(In reply to Frederik Braun [:freddyb] from comment #3)
> That leaves us with dialogs: The dialog-title is immutable. There is no way
> to see where the current site is located. I could imagine having this behave
> like the rocket bar: Tap the title to see and possibly modify the URL.

I'd like to turn the dialog header into the actual rocketbar, so it would behave the same way. We were just short on time in 2.1, but now that we have more breathing space, we can revisit this. We can also explore slightly different styling when it's in this mode. I suppose we'd just have an [X] to close the dialog instead of back/forward buttons.

It seems like if we provide more context in task manager, and an easier way of getting to URLs in a popup dialog, we should be good here?

Looping in Francis as the main UX/Product leads on rocketbar.

	Andrew Sutherland [:asuth] (he/him)
	Comment 5 • 10 years ago

(In reply to Kevin Grandon :kgrandon from comment #4)
> (In reply to Frederik Braun [:freddyb] from comment #3)
> (In reply to Frederik Braun [:freddyb] from comment #3)
> > That leaves us with dialogs: The dialog-title is immutable. There is no way
> > to see where the current site is located. I could imagine having this behave
> > like the rocket bar: Tap the title to see and possibly modify the URL.
> 
> I'd like to turn the dialog header into the actual rocketbar, so it would
> behave the same way. We were just short on time in 2.1, but now that we have
> more breathing space, we can revisit this. We can also explore slightly
> different styling when it's in this mode. I suppose we'd just have an [X] to
> close the dialog instead of back/forward buttons.

Involving the rocketbar does sound best.  Right now the dialog title stuff is spoofable in that an app could create its own fake titlebar that's tappable and lies about where it is (in content).

A while back my hope was that we could have the statusbar change its style to indicate when we had true/Chrome-privileged UI hanging onto the page.  Specifically, in the 'dialog' case, the statusbar might take on a different color which could then bleed into the overlay that happened to be below it.  Now that content can specify the statusbar colors, we've lost that specific option, but it seems like the rocketbar idiom is even better.

The way that the rocketbar smooshes up into the statusbar and pops out again for the Browser app makes it clear that it's an omnipresent URL bar-ish thing.  At least the implication I get is that if I don't see a rocketbar in the statusbar, then the thing I see below it is in fact chrome-privileged and is not being spoofed.  As long as we consistently stick to that, it seems like we/users should be good.  Full-screen support still would be risky, but as long as we do what desktop Firefox does (always reminding you that a specific origin has now gone fullscreen), that seems like it would be fine as long as there's the expected escape hatches (home? top-swipe?) and they can't be intercepted.

	Francis Djabri [:djabber]
	Comment 6 • 10 years ago

> 
> It seems like if we provide more context in task manager, and an easier way
> of getting to URLs in a popup dialog, we should be good here?
> 
> Looping in Francis as the main UX/Product leads on rocketbar.

This sounds good to me. From the pop-up dialogs, I think it should be sufficient to toggle between the title and the URL when tapping on the header. 

In task manager, for web pages, I think it would be best to show the URL in a second line beneath the title, perhaps in a smaller font. What do you think, Eric?

	Andrew Sutherland [:asuth] (he/him)
	Comment 7 • 10 years ago

(In reply to Francis Djabri [:djabber] from comment #6)
> > It seems like if we provide more context in task manager, and an easier way
> > of getting to URLs in a popup dialog, we should be good here?
> > 
> > Looping in Francis as the main UX/Product leads on rocketbar.
> 
> This sounds good to me. From the pop-up dialogs, I think it should be
> sufficient to toggle between the title and the URL when tapping on the
> header. 

Would it be possible to "disappear" the rocketbar from the statusbar and make the pop-up dialog titlebar look more like the rocketbar "bubble" a la my third paragraph in comment 5?  The ability to tap on the title-bar does not stop it from being very spoofable, it just makes it more useful when you're not being spoofed.

And to be clear, what I mean by spoofable is that any random app can create a pixel-perfect dialog-transition and dialog UI that looks like it is showing "https://www.google.com" as produced by the system app.

(Noting that showing the URL in the task-switcher is indeed a good anti-spoofing mechanism, but it's arguably one that users are less likely to discover on their own.)

	Eric Pang [:epang] UX
	Comment 8 • 10 years ago

Francis, we can do something like this for the task manager.  Need info me if we want to go ahead and I'll update the spec and attach.  Thanks!

	Francis Djabri [:djabber]
	Comment 9 • 10 years ago

Looks great to me, thanks Eric!

	Eric Pang [:epang] UX
	Comment 10 • 10 years ago

(In reply to Francis Djabri [:djabber] from comment #9)
> Looks great to me, thanks Eric!

I'll update the spec tomorrow morning, but in case someone has time to work on it here's the font info

Size: 10px (15px on flame)
Weight: Regular, italic (same as above text)
Colour: c7c7c7
Alignment: Vertically centered in between text and card.

Thanks!

	Paul Theriault [:pauljt] (no longer reading bugmail) Reporter
	Comment 11 • 10 years ago

(In reply to Eric Pang [:epang] from comment #8)
> Created attachment 8489939 [details]
> Task_Manager.jpg
> 
> Francis, we can do something like this for the task manager.  Need info me
> if we want to go ahead and I'll update the spec and attach.  Thanks!

Ok maybe a separate bug maybe but can we squeek in an SSL indicator in there too?

	Eric Pang [:epang] UX
	Comment 12 • 10 years ago

I've added the url and ssl lock to the spec. Landscape spec to follow

	Eric Pang [:epang] UX
	Comment 14 • 10 years ago

ssl locks, also included the broken ssl locks in case they are needed.

	Eric Pang [:epang] UX
	Comment 15 • 10 years ago

Please ignore comment 12, I ended up updated the values in the specs :).

If anything else is needed let me know, please flag Francis and myself for ui-review when ready, thanks!

	Andrew Sutherland [:asuth] (he/him)
	Comment 16 • 10 years ago

(In reply to Eric Pang [:epang] from comment #15)
> If anything else is needed let me know, please flag Francis and myself for
> ui-review when ready, thanks!

What's the plan for dealing with spoofy long URLs where the domain is something like https://accounts.google.com.haha.you.cant.see.this.part.because.its.in.the.ellipses.evilattacker.com/?

In the screenshots it's implied that the origin or top-level-domain is shown in the rocket-bar in the screenshot, but if I browse to "behance.net" on my FxOS v2.2 device what I actually see is the title, and it doesn't seem like this spec is calling for any changes in what the rocketbar is doing.

If we assume that we don't have the screen real-estate to actually display the entire URL, maybe it makes more sense to display the top-level-domain with primary priority and the other parts of the origin with secondary priority?  For example, in my hyperbolic but possible example above, the most important part would be "evilattacker.com".  All the stuff that precedes it is arguably less important.

	Frederik Braun [:freddy]
	Comment 17 • 10 years ago

Thanks for highlighting this, Andrew.
It should follow the same path that Firefox Desktop does, where the URL bar content is dark grey and the current domain (eTLD+1) is black.

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 18 • 9 years ago

Freddy, do you think this deserves a security rating? Or is it just a missing feature?

	Frederik Braun [:freddy]
	Comment 19 • 9 years ago

Yes. The rating given earlier (before comment 1) seems still correct to me.

	Al Billings [:abillings - ex-MoCo]
	Comment 20 • 9 years ago

Paul, do you know who in b2g we could assign this issue to?

	Paul Theriault [:pauljt] (no longer reading bugmail) Reporter
	Comment 21 • 9 years ago

No but this should block 3.0. Note this is partially mitigated: the user can see the url of the current page 2 ways currently:

- tap on the address bar (which is allows shown, its just minimised now, instead of hidden)
- long press on the homescreen, which shows the task manager, which shows the URL of the current page.

What I would like to see in v3.0 is something more accessible, and noticeable, and I would also like to see the ability to actually inspect the certificate information. One option could be implementing an equivalent of "View page info" for FxOS. 

Perhaps also improvement the UX of the address bar. For example, show the URL initially as the page is loading. Then maybe 3 seconds after the page is loaded, then we swipe to show the title. We could then reshow the url during scrolling perhaps. We probably need some UX input there. We also need to solve this for Apps too if we going to go with a no-install model.

So I'll take it for now with a view to finding an owner once we work out what to do. I've re-rated this too since technically the initial bug is closed but we want to address the issues above. Including the one raised in comment 16 too.

	Gregor Wagner [:gwagner]
	Comment 22 • 9 years ago

Sam, can you take this one?

	Sam Foster [:sfoster] (he/him)
	Comment 23 • 9 years ago

(In reply to Gregor Wagner [:gwagner] from comment #22)
> Sam, can you take this one?

Yeah I would love to. We do need ux input though. I can see maybe having a means to get to page info from the task manager, but is it an overlay or what? and are there other ways to get to it, and how do we get back to the task manager. Also, as Paul notes, we should assume this applies equally to apps (app://) or browser content.
In parallel to that we should start to spec out what info we want to display. The full URL, certificate info, maybe view-source? cache/offline status?, what else? And is this something we want to make a part of the extensibility api for add-ons?

	Sam Foster [:sfoster] (he/him)
	Comment 24 • 9 years ago

If we have broad consensus that page info is needed, we should close this (worksforme - URLs were displayed in task manager since before 2.0, the lock icon more recently added in bug 1150961) and open a new bug for the new feature.

	Paul Theriault [:pauljt] (no longer reading bugmail) Reporter
	Comment 25 • 9 years ago

(In reply to Sam Foster [:sfoster] from comment #24)
> If we have broad consensus that page info is needed, we should close this
> (worksforme - URLs were displayed in task manager since before 2.0, the lock
> icon more recently added in bug 1150961) and open a new bug for the new
> feature.

I think we should improve the URL bar regardless of additional places to see the url. (along the lines of what I suggested in comment 21) Users are used to seeing the address in the address bar. We definitely need UX input here though.

	Gregor Wagner [:gwagner]
	Comment 26 • 9 years ago

For prioritization.

	Wilfred Mathanaraj [:WDM]
	Comment 27 • 9 years ago

redesign work

	Ryan VanderMeulen [:RyanVM]
	Comment 28 • 6 years ago

FirefoxOS is no longer under active development.