Bug 170285

Summary: REGRESSION (r206744): CSS background-image in style attribute ignored when using createHTMLDocument method of DOM parsing
Product: WebKit Reporter: Martijn Bosgraaf <martijn+webkitbbug>
Component: DOMAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Blocker CC: aestes, cdumez, commit-queue, hyatt, martijn+webkitbbug, rniwa, simon.fraser, webkit-bug-importer, youennf
Priority: P2 Keywords: InRadar
Version: Safari 10   
Hardware: All   
OS: iOS 10   
Bug Depends on:    
Bug Blocks: 162763    
Attachments:
Description Flags
Simplified proof of concept of the issue.
none
Bug proof of concept + image asset
none
Patch none

Martijn Bosgraaf
Reported 2017-03-30 07:55:01 PDT
Created attachment 305861 [details] Simplified proof of concept of the issue. When parsing a HTML string to DOM elements using DOMImplementation::createHTMLDocument background-images no longer get processed when assigned with inline style attributes. This issue did not exist before iOS 10.3 and/or macOS 10.12.4. Simple proof of concept: <!DOCTYPE html> <html> <head> <title>iOS 10.3 / macOS Safari 10.1 - Background image bug POC</title> <style type="text/css">div { width: 10vw; height: 10vh; background-size: cover; }</style> </head> <body> <script> var htmlText = '<div style="background-image: url(image.png)"></div>'; var domdoc = document.implementation.createHTMLDocument('template'); domdoc.documentElement.innerHTML = htmlText; data = domdoc.body.children; for (var i = 0; i < data.length; i++) document.body.appendChild(data[i]); </script> </body> </html> Details to the proof of concept: * The url given in the background-image style property must be a relative or absolute path, NOT a full url. * The issue occurs on the latest macOS 10.12.4 update for Safari as well as iOS 10.3 Safari. * When above code is run and network log is inspected you will notice that the image will never get requested. * When using the webinspector, toggling the background-image style off and back on, the image will be loaded and displayed. * A workaround at the moment can be found in running a javascript that does: "image.src = image.src", this will result in the image being loaded and displayed.
Attachments
Simplified proof of concept of the issue. (582 bytes, text/html)
2017-03-30 07:55 PDT, Martijn Bosgraaf 		no flags
Details
Bug proof of concept + image asset (69.83 KB, application/zip)
2017-04-03 00:55 PDT, Martijn Bosgraaf 		no flags
Details
Patch (4.39 KB, patch)
2017-04-03 13:13 PDT, Chris Dumez 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Chris Dumez
Comment 1 2017-03-30 08:38:14 PDT
Could be related to switching to our new CSS parser maybe?
Radar WebKit Bug Importer
Comment 2 2017-03-31 14:09:57 PDT
<rdar://problem/31378543>
Simon Fraser (smfr)
Comment 3 2017-03-31 14:22:55 PDT
Can you supply a test case with a valid image reference? I can't reproduce after fixing the image URL.
Martijn Bosgraaf
Comment 4 2017-04-03 00:54:03 PDT
The issue can be reproduced with any RELATIVE linked image. I confirmed it to be broken both when loading the HTML from filesystem as well as through a webserver served situation. I added a ZIP file with an update HTML that specifies the version I experience the issue as well as an example image. When you will look at the network requests on the developer inspector you will notice that the image does not get requested.
Martijn Bosgraaf
Comment 5 2017-04-03 00:55:42 PDT
Created attachment 306067 [details] Bug proof of concept + image asset The HTML also has information on the exact macOS and iOS Safari version affected.
Martijn Bosgraaf
Comment 6 2017-04-03 01:00:44 PDT
Safari Technology Preview Release 26 (Safari 10.2, WebKit 12604.1.12) also reveals the same issue as the current macOS and iOS safari issues.
Simon Fraser (smfr)
Comment 7 2017-04-03 11:33:07 PDT
I regressed this to https://trac.webkit.org/changeset/206744/webkit
Chris Dumez
Comment 8 2017-04-03 12:29:46 PDT
(In reply to Simon Fraser (smfr) from comment #7) > I regressed this to https://trac.webkit.org/changeset/206744/webkit Looks like Andy's change caused us to resolve relative CSS image URLs at parsing time instead of loading time. So in cases like the one in this bug (where the image is parsed in one document and then moved to another), we fail to resolve the relative URL. We really need to resolve relative URLs at load time, like we used to, using the loader/document provided.
Chris Dumez
Comment 9 2017-04-03 13:13:20 PDT
Created attachment 306098 [details] Patch
Chris Dumez
Comment 10 2017-04-03 15:06:55 PDT
Comment on attachment 306098 [details] Patch Clearing flags on attachment: 306098 Committed r214842: <http://trac.webkit.org/changeset/214842>
Chris Dumez
Comment 11 2017-04-03 15:06:57 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.