Closed Bug 396816 Opened 17 years ago Closed 16 years ago

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

Categories

(Firefox :: Address Bar, enhancement)

Product:
Firefox
Component:
Address Bar
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.1b2

People

(Reporter: faaborg, Assigned: dao)

References

Details

Attachments

(4 files, 2 obsolete files)

Self describing location bar in Safari 3
(deleted), image/png
Details
Self describing location bar in Opera 9.5
(deleted), image/png
Details
updated patch
(deleted), patch
dietrich
: review+
Details | Diff | Splinter Review
Empty text shown even with cursor in text box
(deleted), image/jpeg
Details 
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
Note the mockup in bug #393508
> 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.
(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.
>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.
(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.
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.
Flags: blocking-firefox3?
This doesn't block, and there's some unhappy implications for not showing the URL that its way too late to iterate on now.
Flags: blocking-firefox3? → blocking-firefox3-
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.
Flags: wanted-firefox3+
(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.
Keywords: uiwanted
Component: Places → Location Bar and Autocomplete
QA Contact: places → 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.

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.
(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.
>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.
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.
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.
Under what circumstances does Safari 3 display that text in the address bar?
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.
(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/
Here is what opera is up to in 9.5
Depends on: 406095
(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.
Assignee: nobody → dao
Keywords: uiwanted
(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.
Where do you see the usability loss?
(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.
(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.
(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.
(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?


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.
>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.

How would that interact with redirecting home pages? (Which, afaik, is the case in Firefox 2 for most languages and distributions)
>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?
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.
>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.
(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).
Hover in the search area on http://www.isohunt.com/torrents/?ihq= and see a way to expose functionality without messing with users.
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"
Keywords: late-l10n
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"
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?
>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.
Attached patch patch (obsolete) (deleted) — — Splinter Review 
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.
Attachment #301265 - Flags: ui-review?(beltzner)
Target Milestone: --- → Firefox 3 beta4
(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.
>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.

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.
Attachment #301265 - Flags: review?(gavin.sharp)
Status: NEW → ASSIGNED
Whiteboard: [has patch]
Bug 410075 helped to make this smoother when opening a new tab.
Depends on: 410075
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 :)
Attachment #301265 - Flags: review?(gavin.sharp) → review+
Comment on attachment 301265 [details] [diff] [review]
patch

ui-r+ on the string; let's land that now
Attachment #301265 - Flags: ui-review?(beltzner) → ui-review+
Attachment #301265 - Flags: approval1.9?
Keywords: checkin-needed
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
Keywords: checkin-needed
Whiteboard: [has patch] → [has patch][has review][has ui-review][needs approval]
Comment on attachment 301265 [details] [diff] [review]
patch

a1.9+=damons
Attachment #301265 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Whiteboard: [has patch][has review][has ui-review][needs approval]
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
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
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.
This got backed out for being a Txul regression.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Location bar should be self describing: "Search Bookmarks and History" → Location bar should be self-describing: "Search Bookmarks and History"
Assignee: dao → nobody
Status: REOPENED → NEW
Target Milestone: Firefox 3 beta4 → ---
Depends on: 420489
As noted in bug 420489 comment #0, this patch also leads the cosmetic issue of read-only location bars also getting the text.
Attached patch second try (obsolete) (deleted) — — Splinter Review 
not sure if this helps
Attachment #301265 - Attachment is obsolete: true
Attachment #307353 - Flags: review?(gavin.sharp)
Can we land this again to find out how much the regression was?
Blocks: 425582
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.
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.
Flags: blocking-firefox3- → blocking-firefox3?
Not blocking, no, but it continues to be wanted.
Flags: blocking-firefox3? → blocking-firefox3-
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
Whiteboard: [missed 1.9 checkin]
Whiteboard: [missed 1.9 checkin] → [not needed for 1.9]
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 :)
Assignee: nobody → dao
Flags: blocking-firefox3.1?
Status: NEW → ASSIGNED
Whiteboard: [not needed for 1.9] → [not needed for 1.9][needs review gavin]
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.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Dao, do we need a new patch for review? Your latest one is really old and has been probably bit-rotted.
Attached patch updated patch (deleted) — — Splinter Review 

        Attachment #307353 -
        Attachment is obsolete: true

        Attachment #344273 -
        Flags: review?(dietrich)

        Attachment #307353 -
        Flags: review?(gavin.sharp)

    
  
Keywords: late-l10n
Whiteboard: [not needed for 1.9][needs review gavin]

    
    

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

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

    
    

    
  
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.

    
    

    
  
(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.

    
    

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

    
    

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

This should be fixed by bug 254714.

    
    

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

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

        Attachment #344273 -
        Flags: review?(dietrich) → review+

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/6c4bb68efd2c
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b2

    
    

    
  
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?

    
    

    
  
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?

    
    

    
  
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?

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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...

    
    

    
  
(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.

    
    

    
  


  
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.

    
    

    
  
(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.

    
    

    
  
(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.

    
    

    
  
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 #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.

    
    

    
  
(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.

    
    

    
  
>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.

    
    

    
  
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.

    
    

    
  
(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?

    
    

    
  
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!
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: