78636 - Caret in location bar should stop meta-refresh until user reloads page

Status: RESOLVED INCOMPLETE

(SeaMonkey :: UI Design, enhancement)

Description

[Adam Masri]

Platform: PowerBook G3/300/192Mb/25Gb, MacOS X 10.0.2
Build ID: 20010417

This bug draws on elements of bug 78630 and bug 78527.

1) Go to my.netscape.com or www.versiontracker.com.
2) Move the mouse into the location bar, select the current URL, make sure to
move the mouse back into the location bar after the select (so you have the
i-beam pointer), and try to type a new URL.
3) Note that the page redraws before you can finish typing! Sometimes a part of
what you typed will be affixed to the end of the URL, Moz will attempt to load
THAT, and you'll often be met with an error from the remote web server that the
page doesn't exist.

What should happen? It would be great if Moz was intelligent enough to postpone
reloading the page while the cursor was in the location bar. Hitting the reload
button would easily return the page to the auto-refresh state, if the user
wanted that.

- Adam

Comment 1

[John Morrison]

whatever.

Comment 2

[John Morrison]

My comment was unconstructive and inappropriate, and I apologize.
As a mozilla contributor since 1998, long before I ever worked at
Netscape, I should have realized that such a flip comment was the
wrong thing to do. It simply reflects the fact that I have been 
spending a great deal of time looking at pages that don't even load,
and UI elements that don't even function, day to day. It would be 
fairly complicated to safely and reliably implement this, and in my
opinion, it is not something that can be done anytime soon. 

But again, let me say that I am sorry for being so flip. I appreciate
your contributions, and did not mean any personal offense.

Comment 3

[Adam Masri]

I just tried this under MacOS 9.1 & Moz 0.8.1, and it doesn't happen there.
Looks OS X specific.

- Adam

Comment 4

[Mike Pinkerton (not reading bugmail)]

dupe.


*** This bug has been marked as a duplicate of 78630 ***

Comment 5

[Adam Masri]

This bug will not be fixed by bug 78630. This behavior isn't even described by
that bug. You might want to run this by sdagley first. Why is this resolved
duplicate?

- Adam

Comment 6

[Adam Masri]

reopening, as this issue has nothing to do with bug 78630. That bug not being
fixed amplified the problem, but the problem is not fixed by fixing that bug.
Let me explain.

Let's say we have a page with a short refresh time, perhaps 30 seconds. Let's
say that you want to go to a different page. So, you click in the location bar,
select text there, delete, and start typing a new page. What will happen after
30 seconds is that Moz will put the refresh URL into the location bar (losing
whatever you typed), and it will start moving to that page. If you didn't notice
Moz was doing this and continued typing, whatever was typed before Moz could
reload the page would become part of the new URL, Moz would try to load THAT URL
from the remote server, and fail.

What this... I guess it's an RFE... is asking for is that when a user is typing
in the location bar, Moz should cancel any refresh or any other operation that
will change the URL bar. The user should be given complete control. If the user
wished the refresh to become reactivated, a simple hit of the reload button
would accomplish this.

I'm not sure, but I believe this RFE is XP. I don't think it's OS X specific. I
would think anybody on any platform would be pleased by this RFE.

- Adam

Comment 7

[Adam Masri]

After thinking about this extensively, I realize that this isn't an RFE. It's a
bug. I set it to RFE status because I didn't want it to get resolved. I doubt
it'll get looked at until the 2.0 timeframe, and there are far more important
issues to work on now, but this will be a problem for anyone with a page with a
short refresh time.

- Adam

Comment 8

[Kathleen :Brade]

I get burned by this a lot myself.  This would be really nice.
In the simpler case, maybe we shouldn't reset the text in urlbar if the caret is 
there or if the user has typed anything since the page started to load or ?

I consider this an enhancement since 4.x browser nor past browsers have had this 
functionality (but it's a subtle distinction perhaps).

Comment 9

[sairuh (rarely reading bugmail)]

marking p5, future, and helpwanted

Comment 10

[Asa Dotzler [:asa]]

-> default assignee

Comment 11

[Peter Trudelle]

->hewitt/future

Comment 12

[Jesse Ruderman]

I don't like the idea of disabling redirects when the address bar has focus.  I
think Mozilla should allow the redirect but try not to blow away something the
user has typed.

The browser frontend already keeps track of whether the text in the address bar
has been changed by the user (userTyped).  Does the frontend know whether a page
load is considered to be the result of a fast automatic redirect?  (A fast
automatic redirect, where fast is something like "less than 15 seconds",
replaces the previous entry in session history.)

Comment 13

[Adam Masri]

I think Moz should do what the user tells Moz to do. If you allow redirects,
then you also allow the location bar to be modified even while the user is
typing something different in it. I think Moz should interpret a mouse click in
the location bar as a Stop button click and a mouse click. That way, Moz stops
whatever it's doing and gives the user the chance to do what they wanted. If the
user wishes to continue, they can just hit reload and keep going with the redirect.

- Adam

Comment 14

[Jesse Ruderman]

I often click on the address bar to copy an address to another window, and I
don't expect that to change the behavior of the page.  I don't even expect
starting to type an address to change the behavior of the page.  If I start to
type an address, that should prevent an automatic redirect from blowing away
what I'm typing, but it shouldn't break the redirect.  Reloading and then
waiting is not an intuitive way to allow a redirect you had been expecting.

Comment 15

[Jesse Ruderman]

*** Bug 105047 has been marked as a duplicate of this bug. ***

Comment 16

[Jesse Ruderman]

*** Bug 162332 has been marked as a duplicate of this bug. ***

Comment 17

[Cor'e]

Just a thought, but any code should also take care of more than moving the mouse focus to the 'Go' button, it should understand that a user may just type a URL and then a CR/Enter leaving the mouse focus still in the box.  jm2c

Comment 19

[Bozhan Boiadzhiev]

Priority P5??!?!?!?
hello!!!! we all using firefox daily!!!!!

Comment 20

[Bozhan Boiadzhiev]

WOW! Last time when i think about this bug was 2007 :)))

Comment 21

[u597032]

Pages no longer active