If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Clicking stop button causes background image to disappear when scrolling



Core Graveyard
17 years ago
9 years ago


(Reporter: Brade, Assigned: dcone (gone))



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-], URL)


(1 attachment)



17 years ago
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!


17 years ago

Comment 1

17 years ago
confirming, win95 081509 (or something near that)
Reporter: Please report separate bugs in separate reports.  Thanks.
Ever confirmed: true

Comment 2

17 years ago
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 ;)
Assignee: clayton → attinasi

Comment 3

17 years ago
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 
Assignee: attinasi → hyatt
Keywords: nsbeta3

Comment 4

17 years ago
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.
Whiteboard: [need info]

Comment 5

17 years ago
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

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

Comment 7

17 years ago
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

17 years ago
->xpapps, per hyatt
Assignee: hyatt → don
Component: Layout → XP Apps
QA Contact: petersen → sairuh

Comment 9

17 years ago
Nav triage team: changing component to Compositor. Here's another URL where you 
can see this problem:
Component: XP Apps → Compositor
over to the compositor owners.
Assignee: don → kmcclusk
QA Contact: sairuh → petersen
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-

Assignee: kmcclusk → dcone
Whiteboard: [need info] → [nsbeta3-]


17 years ago
Target Milestone: --- → Future

Comment 12

17 years ago
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

17 years ago
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

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

Comment 15

17 years ago
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

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


Comment 17

17 years ago
Created attachment 15303 [details]
test case


17 years ago
Keywords: testcase

Comment 18

17 years ago
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

17 years ago
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

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


17 years ago
Keywords: mozilla1.0

Comment 21

17 years ago
*** Bug 68330 has been marked as a duplicate of this bug. ***
*** Bug 50644 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
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

17 years ago
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

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

Comment 26

17 years ago
linux x86 2001-03-14-08

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

Comment 27

17 years ago
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

17 years ago
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

16 years ago
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?
Works for me with 2001102503 build on WINNT.
Marking WFM.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.