Closed Bug 95981 Opened 19 years ago Closed 19 years ago

Changes in background images on pages do not show on reload

Categories

(Core :: ImageLib, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla0.9.2

People

(Reporter: petter.sundlof, Assigned: darin.moz)

References

Details

(Keywords: topembed)

Attachments

(6 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.8 i686)
BuildID:    

Changes made in an image used as the background (for example, <TABLE
background=image.png>) do not show on reload.

Even though the change is visible when viewing and reloading the image on its
own, it does not show when going back and viewing the page.

Reproducible: Always
Steps to Reproduce:
1.Load a page which has a image as the table background
2.Make change to that image
3.Reload

Actual Results:  The changes made in the image do not show

Expected Results:  The changes made in the image should show
Attached image Image background
Attached file Test case
The test case needs to be download, and the source modified so that it points to
the image locally.
Summary: Chanes in background images on pages do not show on reload → Changes in background images on pages do not show on reload
And no, Shift/Ctl+Reload has no effect here. It does work when viewing only the
image -- then the changes are visible (when using combo+reload), but when going
back to the page, the old image is still there. Very odd.
Confirming bug.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
Darin, this looks like a problem with my getting the load flags off the 
document's loadgroup (or default request) potentially after all the loads have 
completed...  I expect that if the loadgroup's loadflags got set properly to 
reflect FORCE_RELOAD, etc that this bug should go away... can you help? :)
Agreed... the load group's loadFlags and defaultLoadRequest are NULL.  The load
group also doesn't have any stored requests (which explains why the default load
request is NULL).  After further investigation it seems that this problem results
from the fact that the load flags are not sticky... meaning that when the
default load request is cleared, the load group clears its load flags.  Breaking
this behavior fixes this bug, and I can't think of any regressions this might
cause, so
I think it is probably the right thing to do.  Attaching a patch...
-> taking this bug... pavlov: can you please review the patch?  thanks!
Assignee: pavlov → darin
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Component: ImageLib → Networking
Keywords: patch
r=pavlov
Whiteboard: r=pavlov, sr=?
sr=me
Whiteboard: r=pavlov, sr=? → r=pavlov, sr=dougt
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: r=pavlov, sr=dougt → r=pavlov, sr=dougt, fixed-on-trunk
reopening... this caused blocker bug 96480.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
patch backed out on trunk
this new patch solves this bug without causing bug 96480.
Status: REOPENED → ASSIGNED
looks good...  r=rpotts
Whiteboard: r=pavlov, sr=dougt, fixed-on-trunk → r=rpotts
okay with me. sr
Whiteboard: r=rpotts → ready-to-land
fixed-on-trunk, i think this may be important for the embedding branch.
Keywords: topembed
Whiteboard: ready-to-land → fixed-on-trunk
Target Milestone: mozilla0.9.4 → mozilla0.9.2
please resolve this as fixed when the checkin happens on the trrunk.  If people
want this for an older branch please file a new bug. This one should be Resolved
Fixed.
Hm, I tried a nightly build, and this worked. I'll mark it as fixed, then.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
asa: that is not the policy i've been following for the 0.9.2 branch.  i
understand that there is going to be some discussion shortly regarding how bugs
effecting the trunk and multiple branches are to be handled, so until i hear the
resolution of those discussions i'm going to stick with my existing policy.

-> reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
tpreston@netscape.com, could you verify the bug on the trunk build before darin
will check this into the 0.9.2 branch? thanks

*** Bug 94409 has been marked as a duplicate of this bug. ***
Verified fixed linux build 2001082908(trunk)
Verified fixed w2k build 2001082803 (trunk)
Verified fixed mac build 2001082905 (trunk)
fixed-on-branch
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
This doesn't appear to be fixed on branch, I'll attach the files I've used to 
test this bug, I use one of the files first, then rename the other one and then 
on reload, nothing changes????
Attached file This is the HTML file
Darnit, I guess I forgot to add the second image!  Anyway, I double checked this
and with build 2001-09-04-22-0.9.2ec on w2k, when reloading after changing the
image, nothing changes, therefore reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
terri, can you confirm that this was fixed on the trunk?  thanks!
Yes, it is fixed on trunk for all platforms but not for branch
terri: did you use the stub installer or the sea installer with the ec build?
i've heard rummors that the stub installer pulls the wrong xpi's.
-> imagelib
Component: Networking → ImageLib
removed the status summary comments -- we are moving to 0.9.4 as the primary
embedding branch (0.9.2 is no longer supported for the embedding customer)
Whiteboard: fixed-on-trunk
resolving FIXED
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.