49222 - Clicking stop button causes background image to disappear when scrolling

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX, defect, P3)

Description

[Brade]

This is a highly weird problem and I hope I'm submitting it to the right entity.
The above page uses an image for the background and the top table cell background.
It scrolls just fine, but if you click the stop button (even when greyed) then
scroll, the parts you scroll into will not contain the background! This results
in a decidedly funky looking page. Give it a try with the URL above.

I want to throw in a few comments as well:
1) I agree with the bug about table widths not being recognized if even one cell
is left unspecified. This needs to be fixed pronto.
2) You cannot press "enter" to submit a form. That's also bad.
3) You cannot right-click paste into a form field. Bad.
4) This is pretty minor, but text wraps around images too tightly. There needs
to be some automatic padding there.

That's all for now!

Comment 1

[Rann Bar-On]

confirming, win95 081509 (or something near that)
Reporter: Please report separate bugs in separate reports.  Thanks.

Comment 2

[Marc Attinasi]

Absolutely and Positively strange! How can clicking on a grayed-out stob button 
cause the background image to disappear? And why doesn't clicking on the 
grayed-out Forward button do it? CC'ing hyatt in case he has some secret 
knowledge of the stop button ;)

Comment 3

[Marc Attinasi]

The problem is that the disabled STOP button ends up being clickable! The click 
causes a call to nsPresContext::Stop(void) and that sets mStopped to TRUE and 
after that no images get loaded because StartImageLoad checks the mStopped.

I think the STOP button should not be clickable when disabled: Dave, whaddaya 
think?

Comment 4

[Peter Trudelle]

We had a bunch of similar cases in 4.x.  Is there some awful thing (crash, data
loss, severe leak scenario) that could happen because of it?  If it is just
background not loading, I'm inclined to just say 'don't do that'.

BTW,I'm ignoring comments 1-4, they would need to be in separate bug reports to
get any action, and are probably dups anyway.

Comment 5

[Marc Attinasi]

All image loading is stopped when you press the disabled STOP button, so it is 
not restricted to  the background image. 

Are you saying Peter that you would lean toward not fixing this? Isn't disabling 
buttons pretty simple?

Comment 6

[Blake Ross]

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

Comment 7

[Blake Ross]

I don't think this has anything to do with the disabled Stop button (that seems 
to be a different bug).  This bug happens when pressing the Stop button, 
disabled or not, or Stop on the context menu.

Comment 8

[Peter Trudelle]

->xpapps, per hyatt

Comment 9

[verah (gone)]

Nav triage team: changing component to Compositor. Here's another URL where you 
can see this problem:
resource:///res/samples/test2.html

Comment 10

[sairuh (rarely reading bugmail)]

over to the compositor owners.

Comment 11

[Kevin McCluskey (gone)]

Don, this sounds like the bug where we don't display the background image if the 
image load has been stopped. 

probably a dup of 40388.

Reassigning to dcone

Marking nsbeta3-

Comment 12

[Marc Attinasi]

The real problem with this bug is that the STOP button is setting mStopped to 
TRUE when we are not even actively loading. If the user is looking at a fully 
loaded page, and then accidentally presses the STOP button (which is disabled 
and should not even be clickable) then we set a flag stopping all subsequent 
image loading - scrolling or resizing causes their background image to 
disappear, and no images can be loaded via the DOM. This seems pretty serious.

Blake Ross indicated that he thought there was a general problem with the STOP 
button, not just when disabled. I reply that if the user presses the STOP button 
while the page is loading then they really will want images to stop loading. If 
they press it when it is disabled then they probably expect nothing to happen.

I cannot see how this is a Rendering problem - the problem is that the UI is 
telling the rest of the system to stop loading, when there is no loading going 
on, and that is wrong.

Comment 13

[Blake Ross]

Marc: I agree that the user wants the images to stop loading if he presses 
Stop.  However, he probably never wants the background of his scrollbar to get 
messed up (see bug 48411).  He probably also doesn't want the background image 
to completely erase -- it should just remain at the point it was at when the 
user decided to stop loading it.

Comment 14

[Eric Vaughan]

Why does this effect chrome? Hitting the stop button should not stop loading ANY 
chrome. Only HTML. Why does mStopped affect everyone?

Comment 15

[Eric Vaughan]

I have a fix for this. I'll post a patch soon. Basically I added an argument 
called aStopChrome to Stop() in nsIPresContext. By default the argument is 
PR_TRUE. If you pass false it stops all images except those that point to chrome 
URLS. Currently all chrome URLs are local to your machine by definition so they 
can't be remote. I think this is a pretty safe solution for 6.0.

Comment 16

[Eric Vaughan]

I have attached a fix for this bug in bug #52663 please review.

-E

Comment 17

[Jesse Ruderman]

Attachment: test case

Comment 18

[uamjet602]

I noticed that this also happens if I open up the bugzilla javascript bookmark
for locating bugs (found on the bugzilla homepage).

Also the background is removed even if it was fully loaded.

Comment 19

[Samuel Sieb]

This also happens when you press ESC.  What really made me notice is on sites
where there are animated icons. I sometimes want to stop them, so I hit ESC.
But then, all the backgrounds go away!

Comment 20

[R.K.Aa.]

this bug happens all over at http://www.sourceforge.net also.

Comment 21

[R.K.Aa.]

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

Comment 22

[Brian Haskin (Janzert)]

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

Comment 23

[Stephen Moehle]

Personally, I would rank this bug higher than minor and future.  If someone uses
ESC to stop the annoying animated ads on a site and the background image
disappears and onMouseOver JavaScript loaded images stop loading (menu bars,
etc.: see the example in bug 68330), I think they will be very surprised and
will be tempted to think Mozilla is very broken.

Comment 24

[Marc Attinasi]

I agree that this should be given higher priority because it is totally lame.

Don, can you address this or find somebody who can? evaughan had indicated that
he might have a fix, but it only fixed the chrome images.

To state my position clearly: Mozilla looks _silly_ if hitting 'escape' causes
background images to go away. How professional ;)

Comment 25

[R.K.Aa.]

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

Comment 26

[Brad Garcia]

linux x86 2001-03-14-08

I no longer see this bug.
Can anyone else confirm that it has been fixed?

Comment 27

[Stephen Moehle]

Clicking the Stop button when it is greyed no longer seems to cause any
problems.  However, pressing the ESC key is still a problem, and it is the more
serious problem in any case.

Comment 28

[R.K.Aa.]

clicking a second time on a "visually disabled stop-button" was "fixed" - it
does nothing now. That was deliberate. (bug 49773) But it only "cloaks" this bug
- it isnt fixed at all.

Comment 29

[Tom Mraz]

This bug seems to be fixed now. Even the ESC keypress doesn't make the
background image to disappear.
Any comments from other people who have seen this bug?

Comment 30

[Kevin McCluskey (gone)]

Works for me with 2001102503 build on WINNT.
Marking WFM.