Open Bug 405244 Opened 17 years ago Updated 2 years ago

Go button persists (no easy and discoverable way to make the star come back)

Categories

(Firefox :: Toolbars and Customization, defect)

defect

Tracking

()

People

(Reporter: chadwickgab+mozilla, Unassigned)

References

Details

(Keywords: uiwanted)

When the go button appears there is no way to make it go away and stay on the same page. You are obliged to press enter.

There should be an easy way to get the star button back. I suggest when address bar loose focus.
No longer depends on: 398020
Blocks: 398020
The star button comes back as you revert the location bar value. That is, press ESC.
Keywords: qawanted
Ok but that is not very discoverable... I still think when the address bar loose focus it should do the same as escape. A similar behavior is seen in vista. When click in the address bar of any folder you get a modified address bar the when it loose focus you get it reverted back to the initial appearance. IMO opinion this should be consistent with the OS following the integration work that the UI is undergoing... Any other opinions ?
Summary: Go button persists (no way to make the star come back) → Go button persists (no easy and discoverable way to make the star come back)
But it fails to come back if you select undo from the context menu.  That should really(In reply to comment #1)
> The star button comes back as you revert the location bar value. That is, press
> ESC.
> 
OK.  But it should really also come back if you select Undo from the location bar context menu.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It would also be nice if right clicking on the Go arrow presented the location bar context menu rather than the customize toolbar menu.  I think that in addition to making Undo from the context menu restore the star satisfy the easily discoverable issue.
(In reply to comment #4)
> It would also be nice if right clicking on the Go arrow presented the location
> bar context menu rather than the customize toolbar menu.  I think that in
                                                                         ^^^^^^^
                                                                         this, in
> addition to making Undo from the context menu restore the star satisfy the
> easily discoverable issue.
> 

 
Flags: blocking-firefox3?
Not blocking, although it would be nice if the field restored itself when the URL was returned to how it was (ie: if I delete the trailing "4" from this URL, then type "4" so it's back to the same URL)
Flags: blocking-firefox3? → blocking-firefox3-
A couple of possible changes:

i. If the URL is changed, and the user then clicks back on the web page, can't we not restore the URL value for the page (i.e. make it behave as escape)

ii. IF Point (i) cannot be implemented, maybe we can bring back the Star Button when the user clicks on the Web Page (even if the URL value is changed i.e. not corresponding to the web page).

For Point (ii) above, we will also have to implement Bug #405344, so that the user does not get confused regarding which page is he trying to bookmark. Instead of selecting the URL bar (when the user hovers or clicks on Star), maybe we could introduce some kind of highlight (like in the case of RSS button... but maybe a little more emphasized) to indicate that the Star button is connected to the web page that he is viewing and not necessarily to the value in the URL bar.
(In reply to comment #7)
> A couple of possible changes:
> 
> i. If the URL is changed, and the user then clicks back on the web page, can't
> we not restore the URL value for the page (i.e. make it behave as escape)
> 
> ii. IF Point (i) cannot be implemented, maybe we can bring back the Star Button
> when the user clicks on the Web Page (even if the URL value is changed i.e. not
> corresponding to the web page).

i. would be the best implementation for me. Easy and coherent. Still is there a use case where the user could want not to lose the modifications he was doing to the address bar. I don't see any current one. ii. Would be confusing to me and not consistent with vista behaviour. 
(In reply to comment #8)
> i. would be the best implementation for me. Easy and coherent. Still is there a
> use case where the user could want not to lose the modifications he was doing
> to the address bar. I don't see any current one. ii. Would be confusing to me
> and not consistent with vista behaviour. 

Sometimes I get a URL in an email that is split over two lines.  I copy the first line into the address bar, then copy the second line into the address bar.  If the URL was reverted when it loses focus, I wouldn't be able to do this.

(In reply to comment #9)
> (In reply to comment #8)
> > i. would be the best implementation for me. Easy and coherent. Still is there a
> > use case where the user could want not to lose the modifications he was doing
> > to the address bar. I don't see any current one. ii. Would be confusing to me
> > and not consistent with vista behaviour. 
> 
> Sometimes I get a URL in an email that is split over two lines.  I copy the
> first line into the address bar, then copy the second line into the address
> bar.  If the URL was reverted when it loses focus, I wouldn't be able to do
> this.
> 

Solution to this problem would be to leave in editing mode on new tab or new window until one page is loaded. Would still be a problem when reusing tab or window but would better middle to the two problems.
The Star button should be restored once the Location Bar loses focus(i.e. the user clicked on the page or the Search Bar).
Depends on: 406779
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.