396816 - Location bar should be self-describing: "Search Bookmarks and History"

Status: VERIFIED FIXED

(Firefox :: Address Bar, enhancement)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

To improve discoverability of the new search features in the location bar, the location bar should include the text "Search Bookmarks and History," in a grey font similar to how the search bar includes the selected search engine.

This text appears in three situations:

-Replaces the URL of the user's home page (but reverts on hover)

-Replaces the URL about:blank (but reverts on hover)

-Appears after creating a new tab

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Note the mockup in bug #393508

Comment 2

[Jesse Ruderman]

> Replaces the URL of the user's home page (but reverts on hover)

Seems like this would invite spoofing and/or users not knowing what page they're on.

> Appears after creating a new tab

Would it appear even though the address bar has focus?  Until the user types the first character?  I don't think I like that.

Comment 3

[Daniel Luz]

(In reply to comment #0)
> -Replaces the URL of the user's home page (but reverts on hover)

Seems a bit confusing to me. Prompt text should only be visible when a field is empty; but when you hover it, it magically gets filled with a lot of text!

> -Appears after creating a new tab

As Dão said in bug 393508 comment #29 and Jesse reiterated here, opening a new tab generally automatically focuses the location bar.

I do understand the importance of discoverability, but I don't think this idea goes in the right direction. IMO the mere fact that some results will appear while the user starts to type an URL would make it discoverable enough. If you want more, maybe it could be mentioned in the default start page.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>Seems a bit confusing to me...it magically gets filled with a lot of text!

I suppose we could simply give you a blank field when you select the location bar on your home page.

>Prompt text should only be visible when a field is empty

A related change would be to display the bookmark title in the location bar, and switch to the location on hover as well.

Comment 5

[Daniel Luz]

(In reply to comment #4)
> >Seems a bit confusing to me...it magically gets filled with a lot of text!
> 
> I suppose we could simply give you a blank field when you select the location
> bar on your home page.

I know, but it would then be a triple-faced field: it says one thing at first, changes when you move your mouse over it, and changes again when you click it.

> >Prompt text should only be visible when a field is empty
> 
> A related change would be to display the bookmark title in the location bar,
> and switch to the location on hover as well.

Now that, at first sight at least, sounds interesting to me. It would be quite user-friendly (would also help to make visually clear when a specific website is truly one you do know, though the star already does that), and the location bar wouldn't really lose its "location" purpose. But doesn't the title of bookmarks most often match the title of the pages they link to? (It's the default value and most people probably don't change it very often, etc) That would make it redundant, repeating something the browser's title bar already says.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Nominating for blocking since I believe discoverability of our new location bar auto-complete is critical to user's understanding why Firefox 3 is so much better than Firefox 2.  This is one of those "how did I ever get by without it" features.

Comment 7

[Mike Connor [:mconnor]]

This doesn't block, and there's some unhappy implications for not showing the URL that its way too late to iterate on now.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Let's keep this bug on topic, please :)

There's precedent for using grey-text which disappears on focus to describe the purpose of an otherwise empty space (ref: search bar in Firefox) and I don't think that it would be confusing if we're careful about where we do it:

> -Replaces the URL of the user's home page (but reverts on hover)

I think this is only useful when the user's home page is Firefox Start, which to many users isn't a "web page" but rather the "Firefox Start Page". In all other circumstances, special casing this could be painful and would definitely be confusing.

> -Replaces the URL about:blank (but reverts on hover)
> -Appears after creating a new tab

The easiest way to do both of these cases is to have it replace about:blank in the location bar. That also prevents us from stomping users who may have set browser.tabs.loadOnNewTab to something other than 0.

Regardless, I don't think this blocks. It's a nice-to-have. Marking wanted.

Comment 9

[Dão Gottwald [:dao]]

(In reply to comment #8)
> There's precedent for using grey-text which disappears on focus
[...]
> > -Replaces the URL about:blank (but reverts on hover)
> > -Appears after creating a new tab
> 
> The easiest way to do both of these cases is to have it replace about:blank in
> the location bar.

It's still not clear how this is really expected to work. If you open a new tab, the location bar is focused. So if you want to clear the text on focus (which I think is more straightforward than on hover), the user would rarely ever see the text.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

>It's still not clear how this is really expected to work. If you open a new
>tab, the location bar is focused. So if you want to clear the text on focus
>(which I think is more straightforward than on hover), the user would rarely
>ever see the text.

Yeah that's a good point.  What if we changed the behavior of both the search bar and the location bar to still be self describing on focus, but with lighter grey text, and the description drops on the first key press.

Comment 11

[Adam Kowalczyk]

(In reply to comment #10)
> Yeah that's a good point.  What if we changed the behavior of both the search
> bar and the location bar to still be self describing on focus, but with lighter
> grey text, and the description drops on the first key press.
> 

It would be too non-standard, I think. I often see average users being confused by this kind of hints. They usually try to manually delete the text before typing.

Comment 12

[Alex Faaborg [:faaborg] (Firefox UX)]

>It would be too non-standard, I think.

That by itself isn't enough to kill an idea, but yeah, we would have to make the font really light to convey that you can type over it.

Just replacing the URL on the home page should be good enough to increase feature discoverability, as well as about:blank when the location bar does not have the focus.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Self describing location bar in Safari 3

Here is what Safari 3 is up to, I believe Opera is doing this as well in their 9.5 alpha, but I'm not sure.

Comment 14

[Dão Gottwald [:dao]]

I'd like to avoid messing around with the color, at least on Windows and Linux. We should stick with the native GrayText, as the background color isn't necessarily white. It's also a good thing that the OS / OS theme can control how faint disabled text should be.

Comment 15

[Jesse Ruderman]

Under what circumstances does Safari 3 display that text in the address bar?

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

I'm not sure every way to get it to do that, but one way is to create a new tab, and then give the focus to the search bar.

Comment 17

[AndrewM]

(In reply to comment #11)
> (In reply to comment #10)
> > Yeah that's a good point.  What if we changed the behavior of both the search
> > bar and the location bar to still be self describing on focus, but with lighter
> > grey text, and the description drops on the first key press.
> 
> It would be too non-standard, I think. I often see average users being confused
> by this kind of hints. They usually try to manually delete the text before
> typing.

While I'm not sure that it could be described as 'standard', this exact behaviour is nevertheless common on Vista. Look at how the password field (when logging on or when the computer is locked) and the search field in the Start Menu look and behave; the password field has the light-grey text 'Password' and the search field has the light-grey text 'Start search'. Both of these disappear as soon as the user starts typing or if the user clicks in the field. This sounds like exactly what was proposed above.

(In reply to comment #13)
> Here is what Safari 3 is up to, I believe Opera is doing this as well in their
> 9.5 alpha, but I'm not sure.

Actually, Opera 9.5 has already had its first beta release. As to how the location bar behaves, I'm not sure about that cos I haven't got round to installing it yet :)

http://www.opera.com/products/desktop/next/

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Self describing location bar in Opera 9.5

Here is what opera is up to in 9.5

Comment 19

[Dão Gottwald [:dao]]

(In reply to comment #16)
> I'm not sure every way to get it to do that, but one way is to create a new
> tab, and then give the focus to the search bar.

We can do that once bug 406095 is in.

Comment 20

[Adam Kowalczyk]

(In reply to comment #19)
> (In reply to comment #16)
> > I'm not sure every way to get it to do that, but one way is to create a new
> > tab, and then give the focus to the search bar.
> 
> We can do that once bug 406095 is in.

Do we really want to trade a longstanding behavior, which has become part of many people's muscle memory, for this? I afraid there's gonna be a huge opposition against this change.

If "it breaks user's basic habits" is not a good enough argument, then consider the following. Isn't making people use the Location Bar more (instead of re-googling pages etc.) one of the main goals of the new design? In the new world it makes even less sense to favour the Search Bar.

In short, we would trade a significant usability change (arguably: usability loss) for a feature which is going to be needed only for a very short time, because once the user learns what the description says, he won't need to see it all the time.

Comment 21

[Dão Gottwald [:dao]]

Where do you see the usability loss?

Comment 22

[Adam Kowalczyk]

(In reply to comment #21)
> Where do you see the usability loss?

I thought it was quite clear from my comment. Let me rephrase it.


1) Even there weren't a usability LOSS, there surely is a usability CHANGE. And even an otherwise neutral change carries certain costs, when it breaks habits of users.

I open a new tab (Ctrl + T or by double clicking) and I type right away. The Location Bar has always been focused when opening a new tab and people have learnt to rely on it, it's got into their muscle memory. Breaking users' habits is always painful and it shouldn't be done unless we expect concrete benefits and have a clear justification why the new behavior is better in the long run.

In this case, the benefit is that the description will help users learn the new functionality of the Location Bar. Because the description is going to be useful for no more than a few days (after which users will have already learnt what it says), it doesn't seem like a big enough win to me.

2) I think it's not neutral change, I think it's a loss. Encouraging people to use the Location Bar more (instead of re-googling pages etc.) is one of the main goals of the new design. Our intentions are that it should become the center of user's navigation, the fastest way to access his/her bookmarks and history. 
How much sense does it make to shift the focus from the Location Bar to the Search Bar, when the other parts of our design go in the opposite direction?

3) The Search Bar has its own description, which wouldn't be visible anymore.

Comment 23

[Tony Mechelynck [:tonymec]]

(In reply to comment #22)
[...]
> 3) The Search Bar has its own description, which wouldn't be visible anymore.

IMHO, this is a definite loss, because the search bar's text (when not focused) tells me which search engine is currently active. You'll tell me that the icon tells me that: but I happen to have several engines which use the same icon, such as:

Wikipedia (English)
Wikipedia (French)
Wikipedia (Esperanto)
Wikipedia (Dutch)
Wikipedia (Italian)

Mozilla Update
Mozilla.org
Devmo
Mozilla Wiki
Bugzilla@Mozilla

Mozillazine Forums
Mozillazine KB

Other search engines have their own icon, but since I use them less often then the above, the icon doesn't tell me much (except for Google and Yahoo): I need the text.

The Location bar, on the contrary, would have only one text string, and I'd even venture that after the first minute, that text would stop playing any critical role. If you absolutely want that text to be visible, please find some way which doesn't prevent a new tab's URL bar from being in focus -- yes, when I click the "New Tab" button or hit Ctrl-T, what I want to do as soon as the new tab opens is use the URL bar: either paste something there, type something there, or type some partwise thing and use completion on it. Therefore its being in focus is a timesaver.

Comment 24

[Dão Gottwald [:dao]]

(In reply to comment #22)
> I open a new tab (Ctrl + T or by double clicking) and I type right away. The
> Location Bar has always been focused when opening a new tab and people have
> learnt to rely on it, it's got into their muscle memory.

We're not going to change that.

Comment 25

[Adam Kowalczyk]

(In reply to comment #24)
> (In reply to comment #22)
> > I open a new tab (Ctrl + T or by double clicking) and I type right away. The
> > Location Bar has always been focused when opening a new tab and people have
> > learnt to rely on it, it's got into their muscle memory.
> 
> We're not going to change that.

Then I am misreading Alex's proposal. Apparently I am not the only one, so could you please explain it a little more?

Comment 26

[Dão Gottwald [:dao]]

What Alex and I meant is that the user leaves the location bar e.g. by focusing the search bar. So the description isn't visible immediately when you open a tab.

Comment 27

[Alex Faaborg [:faaborg] (Firefox UX)]

>Then I am misreading Alex's proposal.

Sorry, that wasn't meant as a proposal.  Jesse asked "Under what circumstances does Safari 3 display that text in the address bar?" referring to the image of I posted of Safari with this attachment: https://bugzilla.mozilla.org/attachment.cgi?id=288752

My reply of "create a new tab, and then give the focus to the search bar" was what you as the user have to do in Safari in order to see this text.

Back to the topic of what we want to do in Firefox.  I propose that we make the location bar self describing for the home page, and when you give it the focus you get a blank field.  The obvious criticisms of this plan are that you are now no longer able to tell if your home page is trying to phish you, send the URL of your home page to a friend, or slightly edit the URL of your home page.  All three of those actions seem sufficiently rare enough to warrant improving the discoverability of the location bar.  Also, the home page URL is still accessible from preferences and page info, in case you really do need it.

Comment 28

[Daniel Luz]

How would that interact with redirecting home pages? (Which, afaik, is the case in Firefox 2 for most languages and distributions)

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

>How would that interact with redirecting home pages? (Which, afaik, is the case
>in Firefox 2 for most languages and distributions)

I suppose we could check against a list of our ~40 localized start pages, (http://www.google.co.jp/firefox, etc.)  How does the redirection work, do our localized Firefox's present a different useragent?

Comment 30

[Jesse Ruderman]

Alex's proposal of hiding the URL when you're on your home page might increase discoverability of some of the autocomplete features of the address bar, but at the expense of discoverability of the address bar's main purpose: to tell you where you are.  I don't think that's worth it.

Comment 31

[Alex Faaborg [:faaborg] (Firefox UX)]

>at the expense of discoverability of the address bar's main purpose

Yes, although I'm viewing its main purpose to be a search field to quickly access pages.  This is because I think users care more about where they are going to go then where they currently are.

Comment 32

[AndrewM]

(In reply to comment #27)
> [...]
> Back to the topic of what we want to do in Firefox.  I propose that we make the
> location bar self describing for the home page, and when you give it the focus
> you get a blank field.  The obvious criticisms of this plan are that you are
> now no longer able to tell if your home page is trying to phish you, send the
> URL of your home page to a friend, or slightly edit the URL of your home page. 
> All three of those actions seem sufficiently rare enough to warrant improving
> the discoverability of the location bar.  Also, the home page URL is still
> accessible from preferences and page info, in case you really do need it.

I think this has the potential to be really confusing, especially for new users, because the behavior is completely different on just one page.

What about your suggestion in comment 10? A slight tweak of this seems like the best compromise to me. How about this:

When you open a new, blank tab or window, the location bar has focus and the light grey text "Search Bookmarks and History" is displayed in the location bar. The text disappears as soon as you start typing or if you hover the mouse over the location bar (and doesn't come back while the location bar has focus, unlike in the Vista search and password examples I referred to in comment 17). "Search Bookmarks and History" would reappear if you click out of the location bar without having entered anything (just like Safari).

I realize this could be a bit annoying for experienced users to have the text reminding them that they can search their bookmarks and history from the location bar, when they already know that, so how about having a counter that counts the number of times that a new tab or window has been opened and only displaying the self-describing text for the first 10 times (or so).

Comment 33

[Roman R.]

Hover in the search area on http://www.isohunt.com/torrents/?ihq= and see a way to expose functionality without messing with users.

Comment 34

[Roman R.]

If you make the location bar say "Search Bookmarks and History", I bet very many people will be looking for the real location bar to enter addresses into. What Nuss proposed on http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/ is much better: "Type Address or Search Bookmarks and History"

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

I was pretty sure there was a clear decision above to *maybe* replace the content on the Firefox Start page (but not user-customized home pages), and *definitely* use the self-describing field instead of about:config.

As for potential text ..:

"Enter a page address, page title or bookmark name"
"Browse the web, or search your history and bookmarks"
"Enter the name or address of where you'd like to go"

Comment 36

[Axel Hecht [:Pike]]

I guess we can do some heuristics for our own builds and the default home page, I'm not sure if this would work for partner builds. Even for our pages, google redirects are somewhat a moving target, so I'm not sure how confident we are that the heuristic we have works in half a year from now.

Additionally, how big is the win here, compared to breaking the string freeze?

Comment 37

[Alex Faaborg [:faaborg] (Firefox UX)]

>how big is the win here, compared to breaking the string freeze?

After two days of using Firefox 3, a friend of mine who is a developer at google hadn't discovered yet that he could enter information into the location bar that wasn't the start of a URL.  Since he would always only enter information that is the start of a URL, it isn't clear how long he would have gone before realizing that the field is now more advanced.  The awesome bar is a flagship features for this release in terms of user experience, so I think letting people know that it exists is a very big win.

Comment 38

[Dão Gottwald [:dao]]

Attachment: patch

This patch is not functional yet. Requesting UI review for the string: "Search Bookmarks and History"

'If you make the location bar say "Search Bookmarks and History", I bet very many people will be looking for the real location bar' seems far-fetched; the Location bar will still display an address most of the time.

Comment 39

[Dão Gottwald [:dao]]

(In reply to comment #35)
> I was pretty sure there was a clear decision above to *maybe* replace the
> content on the Firefox Start page (but not user-customized home pages)

I'm not going to do this; it would be a spoofing risk and a privacy failure.

> *definitely* use the self-describing field instead of about:config.

Yes, assuming you mean about:blank.

Comment 40

[Alex Faaborg [:faaborg] (Firefox UX)]

>This patch is not functional yet. Requesting UI review for the string: "Search
>Bookmarks and History"

I just want to note that I am still in favor of "Search Bookmarks and History." While the user can enter a full URL into the field and hit enter, as they do that we are still going to be searching their bookmarks and history, so the name isn't technically misleading.  

Other reasons I like the short version:

-"Search Bookmarks and History, or Enter a Web Address" feels too long

-Saying something to the effect of "Web Address" gets us into the territory of trying to come up with a human readable name for URL.

-People who know that they can enter a URL are not going to need a self describing search bar to tell them something they already know.

-People who don't know they can enter a URL also probably don't know what a URL is, making the issue a little larger than what the text of the self describing field is.

Comment 41

[Axel Hecht [:Pike]]

In addition, in many languages, that phrase will bloat additionally, and we don't want people to have to scroll to read that they should just type stuff, right? ;-)

Which means, "short" in "few things to say" is key for l10n, a "short" as in "oh, we can zip sentences in English" is more evil than good. Just to make sure that we're not ending up in counting characters, but concepts.

Comment 42

[Dão Gottwald [:dao]]

Bug 410075 helped to make this smoother when opening a new tab.

Comment 43

[Max Karl Ernst]

I'm against this one :) Cluttering UI with basic information seems to go a bit overboard, new users have to learn FEW things at least, and I think that's much better than to fill the UI with "click here for this" notes that normal users have to cope for years to come.   

If someone doesn't know what is address bar, he probably doesn't have any concept of bookmarks or history and that information is just sitting there useless.

If any info at all, I would just add header "Bookmarks and History" somewhere on the pop-up that appears when user starts typing, maybe vertically on the right side. That would inform user what is the thing that he's seeing, and that's the basically what he needs :)

Comment 44

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 301265 [details] [diff] [review]
patch

ui-r+ on the string; let's land that now

Comment 45

[Reed Loden [:reed]]

Checking in browser/locales/en-US/chrome/browser/browser.dtd;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/browser.dtd,v  <--  browser.dtd
new revision: 1.99; previous revision: 1.98
done

Comment 46

[Damon Sicore (:damons)]

Comment on attachment 301265 [details] [diff] [review]
patch

a1.9+=damons

Comment 47

[Reed Loden [:reed]]

Checking in browser/base/content/browser.xul;
/cvsroot/mozilla/browser/base/content/browser.xul,v  <--  browser.xul
new revision: 1.434; previous revision: 1.433
done
Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.183; previous revision: 1.182
done
Checking in browser/themes/pinstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v  <--  browser.css
new revision: 1.126; previous revision: 1.125
done
Checking in browser/themes/winstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v  <--  browser.css
new revision: 1.175; previous revision: 1.174
done

Comment 48

[Bill Gianopoulos [:WG9s]]

I don;t particularly like this change at all.  The example self describing text in the other browsers cited as a reason for doing this say "Hey this where you type the URL in".  The "so called" self describing text here says "This is where you search in stuff you went to int he past".  So, exactly where do you type the URL you want to visit????

I guess Firefox is the browser for people not interested in going where they have not gone before.

Comment 49

[Reed Loden [:reed]]

This got backed out for being a Txul regression.

Comment 50

[Ryan VanderMeulen [:RyanVM]]

As noted in bug 420489 comment #0, this patch also leads the cosmetic issue of read-only location bars also getting the text.

Comment 51

[Dão Gottwald [:dao]]

Attachment: second try

not sure if this helps

Comment 52

[Alex Faaborg [:faaborg] (Firefox UX)]

Can we land this again to find out how much the regression was?

Comment 53

[David Naylor]

Comment #48 has a good point. The self describing text should say something like "Search bookmarks and history, or type and address" if it is to help users with the least knowledge of browsing.

Comment 54

[Alex Faaborg [:faaborg] (Firefox UX)]

I am renominating since I believe resolving this bug is a key part of helping users discover the existence of the flagship UX improvement in Firefox 3.  We might find it silly to think of someone who doesn't know of the awesome bar, but I literally have developer friends at google (who are pretty much as smart as we are) who went for days without realizing that they could search against titles.  When the awesome bar was first included in nightly builds, I remember people around the office not knowing that it had landed.

Comment 55

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking, no, but it continues to be wanted.

Comment 57

[Ed Lee :Mardak]

Just making sure, I should be looking at twinopen from between ~0:00 Feb 23 to ~14:00 Feb 23.

OSX: 442 -> 449, 7ms (1.6%) regression
Win: 244 -> 253, 9ms (3.6%) regression
Lin: 243 -> 256, 13ms (5.1%) regression

http://graphs.mozilla.org/graph.html#spst=range&spss=1203680306.63&spse=1203855890&spstart=1202931767&spend=1209400628&bpst=Cursor&bpstart=1203680306.63&bpend=1203855890&m1tid=148122&m1bl=0&m1avg=0&m2tid=148159&m2bl=0&m2avg=0&m3tid=148119&m3bl=0&m3avg=0

Comment 58

[(mostly gone) XtC4UaLL [:xtc4uall]]

so what is the status here now?
i'm with alex that this could emphasize the possibilities of the locationbar. consider you can search history, tags and even (search)keywords within it now :)

Comment 59

[Dietrich Ayala (:dietrich)]

This is not blocking the 3.1 release. Leaving wanted+, as it might reduce confusion about why certain results show up in the location bar.

Comment 60

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Dao, do we need a new patch for review? Your latest one is really old and has been probably bit-rotted.

Comment 61

[Dão Gottwald [:dao]]

Attachment: updated patch

Comment 62

[Dietrich Ayala (:dietrich)]

Comment on attachment 344273 [details] [diff] [review]
updated patch

Does this address comment 48, comment 51, and the perf regression?

Comment 63

[Dão Gottwald [:dao]]

Comment 48 should be a separate bug. The current string is already ui-reviewed and landed.
Setting the attribute in delayedStartup should help against the twinopen regression, although I'm not sure how using emptytext could cause a regression as massive as 5% in the first place.

Comment 64

[Dietrich Ayala (:dietrich)]

(In reply to comment #62)
> (From update of attachment 344273 [details] [diff] [review])
> Does this address comment 48, comment 51, and the perf regression?

Sorry, I meant comment 50 (bug 420489). Since that's a known issue now, it should be fixed before landing this.

Comment 65

[u88484]

(In reply to comment #63)
> Comment 48 should be a separate bug. The current string is already ui-reviewed
> and landed.
Filed bug 461184

Comment 66

[Dão Gottwald [:dao]]

(In reply to comment #64)
> Sorry, I meant comment 50 (bug 420489).

This should be fixed by bug 254714.

Comment 67

[Dietrich Ayala (:dietrich)]

Comment on attachment 344273 [details] [diff] [review]
updated patch

r=me, thanks. give it another shot, eye on perf.

Comment 68

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/6c4bb68efd2c

Comment 69

[Marcia Knous [:marcia]]

Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081023 Minefield/3.1b2pre and an existing profile, I works when I open a new tab, but if I open another new tab it does not. Is that expected?

Comment 70

[Ed Lee :Mardak]

Just to double check, the first time you open a new tab, your keyboard cursor isn't in the location bar while the second time, it is?

Comment 71

[Marcia Knous [:marcia]]

mardak: thanks for clarifying, now I see that if the focus is away from the location bar that I do see the verbiage show up.

(In reply to comment #70)
> Just to double check, the first time you open a new tab, your keyboard cursor
> isn't in the location bar while the second time, it is?

Comment 72

[Henrik Skupin [:whimboo][⌚️UTC+2]]

How do we want to handle the native Vista behavior? It doesn't only belong to this bug but all text fields with an empty text applied. Vista always show the empty text even when the cursor is located in the text field. Sorry, if there is already a bug about. If not I could file a new one. Alex, what do you think about?

Otherwise I can verify the fix with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081023 Minefield/3.1b2pre (.NET CLR 3.5.30729) ID:20081023034205

Comment 73

[Marcia Knous [:marcia]]

I can verify the fix using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081023 Minefield/3.1b2pre. We will want to check the RTL languages to make sure it displays properly.

Comment 74

[(no longer active)]

(In reply to comment #73)
> I can verify the fix using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5;
> en-US; rv:1.9.1b2pre) Gecko/20081023 Minefield/3.1b2pre. We will want to check
> the RTL languages to make sure it displays properly.

The Force RTL extension <http://ehsanakhgari.org/mozilla/extensions/firefox/force-rtl> can be used for this purpose...

Comment 75

[u88484]

(In reply to comment #72)
> How do we want to handle the native Vista behavior? It doesn't only belong to
> this bug but all text fields with an empty text applied. Vista always show the
> empty text even when the cursor is located in the text field.

I don't have never seen this with Vista.

Dao, is there anyway we can show the text on new tabs while maintaining location bar focus and then when the user starts typing, the text with hide? I just don't see many people opening a new tab and clicking elsewhere to make the location bar lose focus.  In other words, it won't get shown much if at all.

Comment 76

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Empty text shown even with cursor in text box

Kurt, as you can see with this screenshot we are talking about the same thing. As long as you haven't entered a character the empty text is visible.

Comment 77

[u88484]

(In reply to comment #76)
> Created an attachment (id=344476) [details]
> Empty text shown even with cursor in text box
> 
> Kurt, as you can see with this screenshot we are talking about the same thing.
> As long as you haven't entered a character the empty text is visible.

Ahh ok, I thought you meant it was happening in Firefox.  That is what I want and had already filed bug 461352 about it.

Comment 78

[Dão Gottwald [:dao]]

(In reply to comment #75)
> I just don't see many people opening a new tab and clicking elsewhere to make
> the location bar lose focus.  In other words, it won't get shown much if at all.

This might change with bug 455553.

Comment 79

[sibbl]

why is only written "Search Bookmarks and History" - why isn't mentioned that you can write your links you want to visit there, too?!?

Comment 80

[mmortal03]

(In reply to comment #79)
> why is only written "Search Bookmarks and History" - why isn't mentioned that
> you can write your links you want to visit there, too?!?

Good point.  Since it is also the address bar, and even though to most people it is obvious that you still do type the address there, it might be good to make this explicit by re-wording it to include that.

Comment 81

[u88484]

(In reply to comment #79)
> why is only written "Search Bookmarks and History" - why isn't mentioned that
> you can write your links you want to visit there, too?!?

(In reply to comment #80)
> (In reply to comment #79)
> > why is only written "Search Bookmarks and History" - why isn't mentioned that
> > you can write your links you want to visit there, too?!?
> Good point.  Since it is also the address bar, and even though to most people
> it is obvious that you still do type the address there, it might be good to
> make this explicit by re-wording it to include that.

See bug 461184.  Please do not comment in this bug anymore.

Comment 82

[Alex Faaborg [:faaborg] (Firefox UX)]

>why is only written "Search Bookmarks and History" - why isn't mentioned that
>you can write your links you want to visit there, too?!?

We are using bug 461184 for discussion of that.

>How do we want to handle the native Vista behavior? It doesn't only belong to
>this bug but all text fields with an empty text applied. Vista always show the
>empty text even when the cursor is located in the text field.

It does in the start menu, but not in other fields like the search field in
Windows Explorer, IE, Media Player, Photo Gallery, Mail, etc. Although in all
of these cases the field doesn't start with the focus.  They probably kept the
self describing text on the start menu because otherwise it would never appear.

Personally I think this might be one of the cases where we want to
intentionally go against platform behavior.  Removing the self describing text
gives good feedback that the field has been given the focus, but it also
removes the indicator of what you should type before you have started to
actually enter anything.

Comment 83

[Ryan Jones-Ward [:sciguyryan]]

As one can enable and disable specific parts of the "searching" functionality using the new |browser.urlbar.restrict.history| and |browser.urlbar.restrict.browser| features, should those not be used to specify the text shown? For example, if someone has disabled searching their history and find the text stating that they can search their history they may find that confusing too I suppose.

Comment 84

[u88484]

(In reply to comment #82)
> >How do we want to handle the native Vista behavior? It doesn't only belong to
> >this bug but all text fields with an empty text applied. Vista always show the
> >empty text even when the cursor is located in the text field.
> It does in the start menu, but not in other fields like the search field in
> Windows Explorer, IE, Media Player, Photo Gallery, Mail, etc. Although in all
> of these cases the field doesn't start with the focus.  They probably kept the
> self describing text on the start menu because otherwise it would never appear.
> Personally I think this might be one of the cases where we want to
> intentionally go against platform behavior.  Removing the self describing text
> gives good feedback that the field has been given the focus, but it also
> removes the indicator of what you should type before you have started to
> actually enter anything.

Is that your response for bug 461352 also?

Comment 85

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081028 Minefield/3.1b2pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2pre) Gecko/20081028 Minefield/3.1b2pre

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081028 Minefield/3.1b2pre

in-litmus+: https://litmus.mozilla.org/show_test.cgi?id=7389

Please file any and all follow regression bugs separately, thanks!