All users were logged out of Bugzilla on October 13th, 2018

Local images referenced from stylesheet service-registered data URI author stylesheets don't get updated when the image changes or when the stylesheet is re-registered

NEW
Unassigned

Status

()

4 years ago
3 years ago

People

(Reporter: noitidart, Unassigned)

Tracking

Trunk
x86_64
Windows 8.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8479710 [details]
testcase local file caching weirdness scratchpad.js

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140822024446

Steps to reproduce:

Test case attached. Run that code from scratchpad, it opens a new tab with the test case.

1) Copy paste test case code to scratchpad and run it, it opens new tab
2) Click on "applyCss"
3) Click on "Release Img" button, it will download an icon to your desktop
4) However background of the div does not change
5) Reload the tab, the background of the div still does not change
6) Close tab
7) Ctrl Shift T to undo close tab. div bg still blank
8) Run the test case again from scratchpad to open a new tab with this content, div is still blank
9) in new tab hit "removeCss"
10) hit "applyCss" and now background changes
11) Now click on "Aurora Img" it replaces the icon on desktop with another icon
12) div background does not change


Actual results:

file is not cached. which is good this is a local file, caching that doesnt make sense. probably cahcing local files would be bad for performance. but anyways, because its not cached, the file should update as the file on the hd updates no?


Expected results:

div background should update when it sees the file get updated as i cant find this file being cached. or at the least the file should update when i removeCss then applyCss again.
(Reporter)

Comment 1

4 years ago
I probably should mention this can be nsIStyleSheet specific, maybe but i dont think so. Im not sure.

Updated

4 years ago
Component: Untriaged → Untriaged
Product: Firefox → Core
Summary: Weird caching with css and file uri → Local images referenced from stylesheet service-registered data URI author stylesheets don't get updated when the image changes or when the stylesheet is re-registered

Comment 2

4 years ago
"Exception: gBrowser is not defined" when I try to run the js script.

Comment 3

4 years ago
(In reply to Loic from comment #2)
> "Exception: gBrowser is not defined" when I try to run the js script.

You need to set the environment to "browser".
(Reporter)

Comment 4

4 years ago
Oops yeah i forgot to mention that, is it possible to edit comments on here?
(Reporter)

Comment 5

4 years ago
The issue is not "that it never changes" it does change if you tweak around with "applyCss" "removeCss" "close tab" "new tab" in some unknown order and with some repition. It would be nice if we could figure out what it's doing so we can have a formula to work around it, and if its an issue if we can maybe fix it.

It's not just AUTHOR sheets, it also affects if registered as USER sheet.
(Reporter)

Comment 6

4 years ago
I really dont think this is specific to the stylesheet service. I think if you applid the css via overlay addon you will see same behavior when the file on local drive changes.
(Reporter)

Comment 7

4 years ago
You can get the css to take the new file.

To do this:

1) run testcase, opens tab 1
2) run testcase again, opens tab2
3) in tab 1 hit "release img"
4) in tab 1 hit apply css
5) in either tab hit "aurora img"
6) in tab 2 hit removeCss
7) in tab2 hit applyCss
8) tab2 gets the old image applied but switch to tab1 and you see the new image applied
9) switch back to tab2 and remove then apply again and now tab2 takes the new image

total weirdness
(Reporter)

Comment 8

4 years ago
the tab switching has something to do with making it apply the new image. thats why its weird
(Reporter)

Comment 9

4 years ago
Here is a screencast demo'ing the issue: https://www.youtube.com/watch?v=mbGJxHtstrw

Comment 10

4 years ago
Reporter, did it use to work normally in the past?
(Reporter)

Comment 11

4 years ago
(In reply to Loic from comment #10)
> Reporter, did it use to work normally in the past?

I'm not srure @Loic. It's been a problem since I discovered it, i don't know how it worked before that, i never tried.

Comment 12

3 years ago
User Agent 	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID 	20160105164030

Reproduced this on Firefox 43.0.4 following the steps from the bug report and the steps from the video from comment 9. Also I reproduced on Nightly 47 (e10s disabled). With e10s enabled I cannot test the entire flow as "Release Img"/"Beta Img"/"Aurora Img"/"Nightly Img" buttons don't work (no image is saved to desktop).
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Version: 32 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.