Closed Bug 60780 Opened 24 years ago Closed 23 years ago

hitting STOP before any rendering is done causes current web page to become inactive

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 76495
Milestone:
Future

People

(Reporter: brasten, Assigned: jst)

References

(
URL
)

Details

(Keywords: helpwanted) 

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; DigExt)
BuildID:    2000111704

I couldn't find this searching for bugs so sorry if it's been mass duplicated, 
but it only makes sense to me that if I am viewing, say.. www.netscape.com, and 
I type in, say, www.microsoft.com accidentally and immediately hit stop (upon 
realizing my error), it shouldn't deactivate www.netscape.com..  But it seems 
as though the currently rendered webpage become unresponsive while waiting to 
render the next.. if the next one never comes because it's terminated, the 
current one should still be considered the current page and work properly.

Reproducible: Always
Steps to Reproduce:
1. go to any url.
2. go to a second url, but hit stop before page loads up
3. try to interact with the page currently displayed (click on links, etc etc)

Actual Results:  can't do anything

Expected Results:  should be able to

Also, in this case, hitting RELOAD causes the page you TRIED to go to to load 
up... in my opinion, (which could be wrong), if you're still on the first url, 
that one should reload.
I'm seeing this as well on 2000-11-18-20 on NT4.
update:
it's not as easy to reproduce as I originally stated.  it appears as though you 
have to STOP the process right AFTER the server's been contacted (and maybe 
sent a little data) but before enough data has been sent to render any page.  
This is resulting in an url and title from one site, but an unresponsive page 
from another site.  Given the small amount of time in which STOP must be hit, 
perhaps this isn't terribly important... I just seem to do it quite often. :)
clicking the "back" button re-renders original page, tho. page you are still
viewing actually doesn't exist for mozilla anymore and that's why it looks
'inactive', so the easiest resolution would be to clear window contents
imeddiately (at least, signifocantly faster) when mozilla starts to transfer
data and put some "navigation cancelled" or similar message.
over to Layout.
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
Please triage.
Assignee: clayton → jst
Seen this on Linux builds for ages now. OS->All. Why is this a "minor" bug? It
renders the UI useless for pages when it occurs (until people figure out to hit
the back button). Adding self to cc.
OS: Windows NT → All
I get this too all the time, and essentially how I would like it to work is:
The page you are on remains active right until the point it is replaced by the
new page. Only at the nano-second that the next page is visibly rendering do I
want the first page to go inactive. So as long as I can see the page, I can use
it fully. If I decide to alter the link I want to go to, I don't want to have to
press 'stop' 'refresh' then the other link.

Me: Win98 Build: 2000121608.
Actually must note that it is alot harder for me to reproduce now as in months
past, but that's down to Moz being so much faster and slicker and not giving me
time to change my mind before the next page is in (that's good).
I agree though this should be more than 'minor'
I have to agree this bug doesn't seem minor to me.  Perhaps I'm indecisive, but 
I run across it all the time.  Doesn't seen to be something that needs fixing 
TODAY, but it should be fixed before Moz1.0, as it could create quite a 
frustrating headache to average users.
This bug has been marked "future" because the original netscape engineer
workingon this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work in
some way -- please attach your concern to the bug for reconsideration.
Hardware: PC → All
Target Milestone: --- → Future
*** Bug 68848 has been marked as a duplicate of this bug. ***
Clearing URL from "any". Nominating for mozilla0.9. Easy workaround although not
immediately obvious but major loss of function (can't click links, scroll page).
Upping to Normal severity.

People ARE going to notice this, and many may dismiss the product in favour of
IE/Opera if they do not realise that reloading the current page re-activates the
page's links and scrolling view. Some on slow connections may suffer quite a bit
with this.
Severity: minor → normal
Keywords: mozilla0.9
This is a major bug, because
- the page is completely disfunctional
- it happens frequently

It happens frequently that I see an interesting link during the load (when the
old page is still displayed) and I change my mind and want to see that link,
too. So, I stop to open follow both links, but I can't anymore.

Please reconsider for mozilla 0.9.
Severity: normal → major
I would love to look into this, but I simply don't have any time for this in the
mozilla0.9, or mozilla0.9.1 timeframe, if this should be fixed sooner this bug
needs a new owner, unfortunately I don't know who that would be. Maybe someone
could ask around on the newsgroups to see if someone could sign up for this?
*adding self to CC*
might this be more of a History:session bug than a layout bug? Not that Radha
isnt overbusy too :)
jst, but the bug is in your area, isn't it?
Keywords: helpwanted
The bug seems more like a docshell bug to me.  It was originally filed as Layout
and then assigned to jst for triage, not because he was the right person.
Ben, possibly, but as David says it's also related to docshell, I actually
discussed this with rpotts a week ago or so and he thought that it wouldn't be
too hard to leave the current document active for a while longer until we know
we actually have something to show in the new document (which could be a while
if the new document uses stylesheets that are loaded "synchronously" while the
parser is blocked.

This doesn't change my statemet tho, I still don't have any time to spend on
this now.
*** Bug 68897 has been marked as a duplicate of this bug. ***
Isn't this a dupe of bug 5569 ?
no, close, but not quite.
Related to, or perhaps even a duplicate of, bug 76495.

Ack!   I detect some circular dupe-logic here!     One of these has to be the
"real" one.  :)

*** This bug has been marked as a duplicate of 76495 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.