Add tests for BiDi network events for cached images
Categories
(Remote Protocol :: WebDriver BiDi, task, P3)
Tracking
(firefox133 fixed)
| Tracking | Status | |
|---|---|---|
| firefox133 | --- | fixed |
People
(Reporter: jdescottes, Assigned: jdescottes)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [webdriver:m13], [wptsync upstream])
Attachments
(2 files)
Similar to cached stylesheets (Bug 1879438), cached images need to be monitored in the content process.
See DevTools implementation over at https://searchfox.org/mozilla-central/rev/b73676a106c1655030bb876fd5e0a6825aee6044/devtools/server/actors/resources/network-events-content.js#52-62
|
||
Comment 1•10 months ago
|
||
The severity field is not set for this bug.
:whimboo, could you have a look please?
For more information, please visit BugBot documentation.
|
Assignee | |
Updated•10 months ago
|
|
||
Updated•9 months ago
|
|
|
Assignee | |
Comment 2•4 months ago
|
||
This should be fixed by Bug 1919218, so let's repurpose this bug to add browser mochitests for JS+image and wdspec tests for cached image requests.
|
|
Assignee | |
Comment 3•4 months ago
|
||
Quick question for images, as I was adding a test for this resource with the BiDi CachedResourceListener:
If an image is already loaded and cached in the page, and we add an iframe in the page which attempts to load the same image, should this new image trigger a fetch and hit the cache?
In other words for the following markup:
(top level page)
<html>
<body>
<img src="https://example.com/browser/remote/shared/listeners/test/browser/cached_resource.sjs?type=image">
<iframe src="https://example.com/document-builder.sjs?html=cached_css_frame"></iframe>
</body>
</html>
(iframe)
<html>
<body>
<img src="https://example.com/browser/remote/shared/listeners/test/browser/cached_resource.sjs?type=image">
</body>
</html>
Should we expect to perform a fetch for the image in the iframe?
Testing locally I don't see any request at least.
|
|
Assignee | |
Comment 4•4 months ago
|
||
While writing a wdspec test for images I noticed another discrepancy compared to chrome.
The scenario is as follows:
- load a page with an <img> tag pointing to a URL returning proper caching headers
- reload the page (-> here we get a notification for the cached image request)
- load a similar page, but which includes 2 <img> tags for the same URL as in the previous page
Here I get no notification at all, whereas in Chrome I do get an event. Is this something which might be wrong in our implementation?
|
||
Comment 5•4 months ago
|
||
I don't know much about the image cache's implementation.
My understanding is that the behavior is reflecting the following spec steps, which uses "the list of available images" below.
If the "the list of available images" contains the image, it doesn't reach the "fetch" step.
https://html.spec.whatwg.org/#updating-the-image-data:list-of-available-images
When the user agent is to update the image data of an img element, optionally with the restart animations flag set, optionally with the maybe omit events flag set, it must run the following steps:
...
7. If selected source is not null, then:
...
4. If the list of available images contains an entry for key, then:
...
8. Abort the update the image data algorithm.
...
26. Fetch the image: Fetch request. ...
Then, the spec says the entries in the list of available images "may" be copied to another documents. Which would mean that the number of fetches is not actually deterministic in term of the spec, and it's up to the implementation, maybe?
https://html.spec.whatwg.org/#the-list-of-available-images
Each Document object must have a list of available images. Each image in this list is identified by a tuple consisting of an absolute URL, a CORS settings attribute mode, and, if the mode is not No CORS, an origin. Each image furthermore has an ignore higher-layer caching flag.
User agents may copy entries from one Document object's list of available images to another at any time (e.g. when the Document is created, user agents can add to it all the images that are loaded in other Documents), but must not change the keys of entries copied in this way when doing so, and must unset the ignore higher-layer caching flag for the copied entry.
User agents may also remove images from such lists at any time (e.g. to save memory). User agents must remove entries in the list of available images as appropriate given higher-layer caching semantics for the resource (e.g. the HTTPCache-Controlresponse header) when the ignore higher-layer caching flag is unset.
anyway, it would be better asking people who implements the image loading.
forwarding to emilio.
|
|
Assignee | |
Comment 6•4 months ago
|
||
Thanks for the insights. It might be something difficult to test in a cross browser way in that case.
|
||
Comment 7•4 months ago
|
||
Yeah if you want to test the available image cache you need to basically start fresh (add a dummy query parameter or something), and that still only works for the same-document case.
|
|
Assignee | |
Comment 8•4 months ago
|
||
|
||
Updated•4 months ago
|
|
|
Assignee | |
Comment 9•4 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
Yeah if you want to test the available image cache you need to basically start fresh (add a dummy query parameter or something), and that still only works for the same-document case.
Thanks! Do you also confirm that
User agents may copy entries from one Document object's list of available images to another at any time
implies that we can't really test scenarios where cached images are reused from one document to another in a cross browser manner?
|
|
Assignee | |
Comment 10•4 months ago
|
||
Depends on D224505
|
|
||
Updated•4 months ago
|
|
|
||
Updated•4 months ago
|
|
||
Comment 12•4 months ago
|
||
|
||
Comment 14•4 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/700db3fe7394
https://hg.mozilla.org/mozilla-central/rev/f22ae80101e8
|
|
Assignee | |
Updated•4 months ago
|
Description
•