82863 - aborting page loading leads to wrong URL display

Status: VERIFIED WORKSFORME

(SeaMonkey :: Location Bar, defect)

Description

[Jens Glaser]

W/Build 2001052308

If you load a page in mozilla and press ESCAPE or click on the STOP button
quickly enough the page will not be loaded, which is okay. But the URL
display changes, so that the new URL is displayed while still the
old page is visible! This is irritating.

What is even more irritating is that in this incosistent state you can
still roll over links of the old page and they are displayed in the status
bar but you cannot click on them.

Workaround: click on BACK (this goes back to the old URL and reloads the
current page)

It would be nice if the URL display would only be changed if the html
window contents are actually changed.

Comment 1

[Boris Zbarsky [:bzbarsky]]

That would actually cause a different bug in which you click on a link and it 
never loads and you can't edit the url to fix it because the URL is not in the 
url bar.  Especially bad if one has done "open link in new window"....

Comment 2

[James Green]

->Event Handling...

Comment 3

[James Green]

->Event Handling...

Comment 4

[James Green]

OK the behaviour of what the GUI and history reacts to when a new page comes
along was changed by hyatt, he took the bug from joki if my memory serves me.
Adding hyatt as cc, although I don't suppose this bug will actually be
considered a high enough priority for 1.0 release.

We should only load the new URL in the URL bar (and thus update history) once we
have sufficient data from the new page to draw something. This could be blanking
the viewport to the background colour of the new page or something, but it
mustn't happen until we can safely draw *something* for the new page.

If we change the urlbar before we draw something for the new page, then we are
jumping the gun and saying that we are loading it when we (to the user) haven't
started. This messes up the GUI as the user states.

So we need:
1) Click on link
2) Begin download of page
3) Initial paint
4) Update urlbar and history (without interruption)

If we hit ESC begin 1) and 2) nothing in the urlbar or history or viewport
changes. It's as if we never clicked the link.

If we hit ESC between 2) and 3) again nothing happens.

If we hit ESC between 3) and 4) we should go ahead with 4) else it's not going
to make any sense to the user.

If we are opening a new window, then we should keep the urlbar and history blank
until step 3) as per normal page load in existing window.

All imho :) I'm confirming this for further discussion.

Comment 5

[Madhur Bhatia]

QA contact updated

Comment 6

[joki (gone)]

Not really an event handling issue.  Possibly history?  Whoever owns URL Bar 
bugs should be able to figure out where it should go.

Comment 7

[Alec Flett]

reassign url bar bugs to new owner..

Comment 8

[Blake Ross]

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

Comment 9

[Joe Hewitt (gone)]

A long time ago, hyatt changed the page loading behavior so the old document
would stay alive until the moment the new one was ready to paint.  Not sure if
that happened before this bug report, but nevertheless I can't reproduce this
anymore.

Comment 10

[sairuh (rarely reading bugmail)]

mass-verifying WorksForMe bugs which haven't changed since 2001.12.31.

set your search string in mail to "EmperorLondoMollari" to filter out these
messages.