Unnecessary requests re-sent for a cached image with only the hash at the end of the URL changed

RESOLVED DUPLICATE of bug 1027106

Status

()

--
minor
RESOLVED DUPLICATE of bug 1027106
2 years ago
8 days ago

People

(Reporter: mardeg, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Reporter)

Description

2 years ago
Created attachment 8867515 [details]
SVG file for testcase

Tested in latest Nightly on Linux 32-bit, in the devtools network monitor I'm seeing the same URL request being re-sent when javascript is used only to change the part of an SVG image address after the # (it's a sprite sheet of a dozen images with <view>s of each.

STR: 
1. Open the attached testcase and devtools network monitor.
2. Choose a version of the image by host (please don't hammer imgh.us)
3. Click the image to see the next sprite
4. Check the network requests.

Actual behaviour: Each time the image is clicked the same URL is re-requested over the internet.

Expected behaviour: There should be a check done when the img .src attribute is set and no part before the # has changed, to prevent an unneeded round trip to a server. Chromium does this check and the image changes instantly in response to clicks.
(Reporter)

Comment 1

2 years ago
Created attachment 8867516 [details]
img src testcase

Note the #dc01 at the end of the img src URL ascends to #dc02 etc. for the next sprite up to #dc12 and cycles back to the beginning.
Component: Networking: Cache → DOM
I am 95% positive that we have tests that depend on the fragment behavior not hitting in the image cache.
No longer blocks: 1347376

Comment 3

2 years ago
Daniel, do I remember correctly that this is a known issue with SVG images?  I remember running into a similar issue when working on tab audio indicators where we also use SVG images with URLs with hashes at the end where we refetch the image similarly...  I can't find the bug# right now.
Flags: needinfo?(dholbert)
(Reporter)

Comment 4

2 years ago
Preserving a comment here from bug 1347376 comment 9

> it occurs to me the best way to make LoadImage() faster is not to call it at all.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1121693
tnikkel found the correct dupe-target -- thanks!

(Per bug 1121693 comment 8, this isn't SVG-specific -- it happens for whatever.jpg#dc01, whatever.jpg#dc02, etc. too -- though it's more likely that someone would want to use a #ref with a SVG image.)
Flags: needinfo?(dholbert)
Component: DOM → ImageLib
(Reporter)

Comment 7

2 years ago
Created attachment 8882937 [details]
SVG file for testcase #2
(Reporter)

Comment 8

2 years ago
Created attachment 8882939 [details]
Caption file for testcase #2
(Reporter)

Comment 9

2 years ago
Created attachment 8882940 [details]
OGA file for testcase #2
(Reporter)

Comment 10

2 years ago
Created attachment 8882943 [details]
MP3 file for testcase #2
(Reporter)

Comment 11

2 years ago
Created attachment 8882944 [details]
testcase #2

Shows how crucial having no delay from a "load" cycle is.
(Reporter)

Updated

8 days ago
OS: Linux → All
Hardware: x86 → All
Duplicate of bug: 1027106
You need to log in before you can comment on or make changes to this bug.