15050 - page load shouldn't overwrite text typed into the url bar

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect, P3)

Description

[Neil Marshall]

If I'm typing in the URL bar, I just hate it when the browser finishes
loading the page and it erases half of what I've just written.  If I've
started writing in the urlbar, all updates to it should be ignored,
until I submit the url (enter or a go button).  The Undo button (ctrl-z) could
bring back the url as it does in 4.

Other people I know get around this by pressing ctrl-o to open a url everytime,
or they set navigator to load to a blank page, that way when you press ctrl-n,
tab the url bar is blank and stays blank.  Personally, when I open a new
window or start typing in the location bar, I'm in the habit of pressing escape
before typing.  But these are all sloppy workarounds.

Comment 1

[don]

Radha, this would actually be a good thing to fix before we ship since I think
this is the behavior in 4.x.  (And if not, it SHOULD be the behavior in 4.x. :-)

Comment 2

[don]

Move to M15.  Not required for beta 1.

Comment 3

[leger]

Updating QA Contact.

Comment 4

[Claudius Gayle]

after checking this out with recent builds(2000042512) this still applies in the real world. to test I tried typing while the current 
page reloads(text overwritten) and I tried typing after entering just a word in the url field (to force a lookup), my text was over 
written there as well.

Comment 5

[don]

Move to M20 target milestone.

Comment 6

[Jesse Ruderman]

complementary bug: 32194

Comment 7

[R.K.Aa.]

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

Comment 8

[Viswanath Ramachandran]

nav triage team: looked at this bug, it is not a beta stopper. bulk update of 
several such bugs. 

Comment 9

[Alec Flett]

moving these bugs to History: URLBar

Comment 10

[Ben Ruppel]

I don't think this is a history related bug.  The situation referred to in the
description involves the fact that NS4 will always replace whatever you are
typing in the url bar with the current page when it finishes loading.  

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comments from duplicate bug:

Problem:

A user can be typing a URL into the address field when the browser changes the 
URL in the middle of typing. Instances where this happens:

1. New window. User launches Mozilla (or hits Ctrl+N) and immediately begins 
typing a URL. If Mozilla is set to load a homepage it may complete loading 
before the user has finished, replacing whatever they wrote.
2. With refreshes/redirects. A user starts typing just before a refresh/redirect 
occurs. Redirect occurs, replacing whatever they wrote.

Solution:

If the user begins typing (or highlighting) a URL, the address field should be 
prevented from changing due to page loads etc. Once focus moves from the field 
and perhaps even a few seconds after that, the browser can restore the field to 
the current URL.

On a personal note, this problem bugs the hell out of me because IE, NS and now 
Mozilla all suffer from it. On a slow link the problem is exacerbated because 
the slower load times make it more likely that you will start typing a new URL 
before the current page has finished loading.

Comment 13

[Jesse Ruderman]

See also bug 40305, "[RFE] browser should only go to autocompleted URL if 
explicitly told to."

Comment 14

[Paul Chen]

Ok see if we can fix this, marking nsbeta1+, mozilla0.9. We should probably do
the hittine "esc" resets url bar to loaded url bug along with this

Comment 15

[Peter "jag" Annema]

This should be fairly simple if we get some cooperation from the urlbar.
oninput="this.setAttribute('typing','true');"

then in onLocationChange (in the XULBrowserWindow):
if (gURLBar.getAttribute("typing") != "true")
  gURLBar.value = location; //
gURLBar.removeAttribute("typing");

Something along those lines. Sound right, Alec?

Comment 16

[Alec Flett]

yup, I'll see about a patch...thanks for the idea..

Comment 17

[Alec Flett]

as much as I'd like to fix this in mozilla 0.9, I am overloaded and must push
this back a milestone. Sorry!

Comment 18

[Viswanath Ramachandran]

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 

Comment 19

[Paul Chen]

nav triage team:

Pushing out to mozilla0.9.3, low impact, high bang for the buck type of fix, we 
hope ;-)

Comment 20

[Paul Chen]

nav triage team:

Yes, it's annoying, but don't think it's a mozilla0.9.3 stopper. Marking 
mozilla1.0

Comment 21

[basic]

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

Comment 22

[Paul Chen]

nav triage team:

Not a 0.9.4 stopper, leaving at mozilla1.0

Comment 23

[r0polach]

If location box is filled when window STARTS CONNECTING to host
(not when page starts loading or (!)finishes loading) there would
be 90% cases solved (workaround).

Comment 24

[Jesse Ruderman]

See also bug 54321, URL Bar should retain focus after a page change.

Comment 25

[Alec Flett]

reassign url bar bugs to new owner..

Comment 26

[Blake Ross]

Joe was dying to have these bugs. Who am I to say no?

Comment 27

[jag (Peter Annema)]

Attachment: This should fix it.

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 54648 [details] [diff] [review]
This should fix it.

[s]r=[e-mail] with the userType->userTyped change.

Comment 29

[jag (Peter Annema)]

Attachment: The "it was late" fix-up.

Comment 30

[jag (Peter Annema)]

So here are a few alternatives:

1) instead of onkeypress, use oninput (user actually modified the url).
   This means ignoring cursor movement like Home, End, left, right.
   We may need to use oninput (in addition to onkeypress) anyway for when
   a user pastes something through the context menu.

2) instead of onkeypress, use onfocus, with the assumption that focusing
   the urlbar is an indication of wanting to keep the text.

3) ... ?

mpt?

Comment 31

[Joe Hewitt (gone)]

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

Comment 32

[Joe Hewitt (gone)]

jag has already worked on this, so he should own it

Comment 33

[jag (Peter Annema)]

-> 0.9.8

Comment 34

[Matthew T (active 1999-2002)]

(1)

Comment 35

[Tuukka Tolvanen (sp3000)]

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

Comment 36

[Joe Hewitt (gone)]

r=hewitt

Comment 37

[jag (Peter Annema)]

Per discussion with mpt on #mozilla, I've changed the onkeypress to oninput. 
hewitt's r= was for the patch with that change in mind, and I'm assuming ben's 
sr= to still be valid.

Checked in, marking fixed.

Comment 38

[mdimitrio]

The problem is still happening in Mozilla build id 2001111008, on Win98.

How to reproduce:

1. Load some page, like http://www.cnet.com/ .
2. Click on one of the links.
3. Now click fast on the url bar and type something. You don't have to go so
fast if you're on a slow connection though.

Result: If you type the text before the page started loading, the text typed
into the url bar will be replaced.

Expected: Your text remain intact, no matter what.

The original report says "...I just hate it when the browser finishes
loading the page and it erases half of what I've just written...", which limits
the bug to text replacing only when the browser finishes loading, but my
comments are valid based on the title that says "page load shouldn't overwrite
text typed into the url bar", which is broader, and also based on comments #12.

Marcos.

Comment 39

[Boris Zbarsky [:bzbarsky]]

Marcos, please look at the times.  Your build is from _before_ this bug was fixed.

Comment 40

[mdimitrio]

Ok, sorry for that.

It must be because I always download the "mozilla-win32.zip" file, and as we
speak, the date of that file in the FTP directory is "10-Nov-2001", not
"11-Nov-2001" as "mozilla-i686-pc-linux-gnu.tar.gz" is.

I'll try it tomorrow. Sorry again.

Marcos.

Comment 41

[mdimitrio]

Yes, it's working now :-)

Marcos.

Comment 42

[Adam Lock]

Jag, can you double check your changes to onLocationChange please? It looks as
though there is stuff in this handler that you want to do irrespective of
whether the user is typing or not, such as update the history buttons.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/nsBrowserStatusHandler.js#254

Comment 43

[jag (Peter Annema)]

Doh! I'll address that in another patch I need to make to this.

Comment 44

[Adam Lock]

REOPEN :)

Comment 45

[jag (Peter Annema)]

See bug 109650 for the patch.

Comment 46

[jag (Peter Annema)]

Patch in bug 109650 checked in, marking fixed again.

Comment 47

[Ryan Pertusio]

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

Comment 48

[Mike Schiraldi]

<QA Ignore>

Oh, thank you thank you thank you ... i've subconsciously hated this behaviour 
of both Moz and IE, and i never even thought about it much, but i know it's 
frustrated me many a time. Reading through the 0.9.7 release notes, i saw this 
bug mentioned and thought, "Oh my god, other people hate that too?"

Comment 49

[John Villalovos]

The fix for this bug seems to break the URL from appearing when you go to web sites.

Type in a URL to a website.  The URL will show up in the URL bar.

Then select a URL from your bookmarks.  Notice that the URL does NOT change in
the URL bar.  It still shows the URL that you typed in before.

Comment 50

[[not reading bugmail]]

John,

it does change after the page starts loading.. till then it doesn't change as
the page content has not changed yet, so this should not be problem, this is
much better than before.

Comment 51

[Biju]

firefox have the same issue now
http://bugzilla.mozilla.org/show_bug.cgi?id=188723