17844 2008-03-14 04:48:41 -0700 Acid2 (no data): WebKit starts a download for the data in an embedded object element 2025-11-21 12:52:10 -0800 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) Mac OS X 10.5 NEW http://hixie.ch/tests/evil/acid/002-no-data/ HasReduction P2 Normal --- 4911 1 webkit zwarich ardreyshaun ddkilzer webkit zooz.sah3 zwarich oldest_to_newest 73719 0 webkit 2008-03-14 04:48:41 -0700 It's not duplicate of bug 4911. It's a 'brand' new Acid2 (no data) bug. Summary: On this page http://hixie.ch/tests/evil/acid/002-no-data/ there is a combination to object elements: <object data="data006"><object data="http://www.damowmow.com/404/" type="text/html">[...]</object></object> data006 is text/html file: curl -I "http://hixie.ch/tests/evil/acid/002-no-data/006" HTTP/1.1 404 Not Found Date: Fri, 14 Mar 2008 11:28:00 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 Accept-Ranges: bytes Vary: Accept-Encoding X-Pingback: http://tracking.damowmow.com/ Content-Language: en-GB-x-Hixie Content-Type: text/html; charset=utf-8 the second data is also text/html file: curl -I "http://www.damowmow.com/404/"HTTP/1.1 404 Not Found Date: Fri, 14 Mar 2008 11:43:16 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 Last-Modified: Mon, 11 Jul 2005 02:17:49 GMT ETag: "ed2bb7-360-63d98d40" Accept-Ranges: bytes Content-Length: 864 Vary: Accept-Encoding X-Pingback: http://tracking.damowmow.com/ Content-Language: en-GB-x-Hixie Link: </resources/images/astrophy/16>; rel="icon" Content-Type: text/html; charset=utf-8 So if you load the test case in Webkit, the engine should not download any file. It's not true in the latest Webkit nightly. Webkit download 006 file. Steps to reproduce: 1) Go to this page:http://hixie.ch/tests/evil/acid/002-no-data/ 2) Notice the Webkit download '006' file. Expected behavior: No file should be download Current behavior: 006 file is downloaded. 73720 1 19759 webkit 2008-03-14 04:49:10 -0700 Created attachment 19759 minimal test case 73729 2 webkit 2008-03-14 07:38:02 -0700 Strange. Currently 006 file is sent with Content-Type: application/x-unknown instead of text /html: curl -I "http://hixie.ch/tests/evil/acid/002-no-data/data006" HTTP/1.1 200 OK Date: Fri, 14 Mar 2008 14:33:46 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 Last-Modified: Tue, 31 May 2005 12:02:17 GMT ETag: "1a9dad7-5-c6926440" Accept-Ranges: bytes Content-Length: 5 X-Pingback: http://tracking.damowmow.com/ Content-Language: en-GB-x-Hixie Content-Type: application/x-unknown 74846 3 zwarich 2008-03-23 00:54:59 -0700 I can't reproduce this if I just host the data file somewhere else, although my hosting gives it either text/plain or text/html, not application/x-unknown. Since the problem still occurred back when it was hosted as text/html, I don't think that's the problem. The 404 doesn't seem to be special, because the problem still occurs with other 404 pages out there. I'll try to get to the bottom of this. 74847 4 19979 zwarich 2008-03-23 00:58:05 -0700 Created attachment 19979 Further reduction The 404 and the fallback content are seemingly irrelevant to this bug. Here is a file without them that still reproduces the problem. 74866 5 zwarich 2008-03-23 11:24:58 -0700 I think I found why we (In reply to comment #2) > Strange. Currently 006 file is sent with Content-Type: application/x-unknown > instead of text /html: I think I figured this out. The page was probably never sent with text/html. In your original post you paste the following snippet of HTML: <object data="data006"><object data="http://www.damowmow.com/404/" type="text/html">[...]</object></object> However, you curl'd "006", which doesn't exist, not "data006". It was downloading data006, which has type application/x-unknown, just like the corresponding data URL in the single page test. Starting a download is still a bug, though, and I'll change the name to reflect that. 74867 6 webkit 2008-03-23 11:39:48 -0700 (In reply to comment #5) > However, you curl'd "006", which doesn't exist, not "data006". Uh... My fault. Sorry for the mess :( 74868 7 zwarich 2008-03-23 11:44:23 -0700 (In reply to comment #6) > (In reply to comment #5) > > > However, you curl'd "006", which doesn't exist, not "data006". > > Uh... My fault. Sorry for the mess :( No mess, I saw it as soon as I started debugging. ;-) There are two ways to fix this. The first is to change the policy check code on the WebKit side, and the second is to change MainResourceLoader to ignore it in this case. I am leaning towards the second, but I will need to run some tests with other browsers to see what happens with iframes, framesets, etc. 74870 8 19984 webkit 2008-03-23 11:58:18 -0700 Created attachment 19984 test case with data URI (ok) Cameron, the crucial question in this case is: why data URI behaves differently? 74871 9 zwarich 2008-03-23 12:08:08 -0700 (In reply to comment #8) > Created an attachment (id=19984) [edit] > test case with data URI (ok) > > Cameron, the crucial question in this case is: why data URI behaves > differently? There is never a policy check on the data URI, so the issue doesn't come up. I'll try to figure out what happens instead. 74897 10 zwarich 2008-03-23 18:32:49 -0700 The data URI version never creates a MainResourceLoader for the data URI, so it is using completely logic entirely. I have a fix for this, which blocks all downloads from object elements by simply ignoring the content policy from the WebFrameLoaderClient. Maciej says that WebKit may be the wrong place to make this policy, and that it may require changes in the API to allow WebKit clients to make the choice themselves. I'll post the fix when I get to school, along with some tests and examples of what other browsers do in similar situations. 74918 11 19993 zwarich 2008-03-23 21:29:54 -0700 Created attachment 19993 Preliminary patch Here is a preliminary patch. Maciej says that WebKit may be the wrong place to make this policy decision, and that we should possibly make it a client preference. 74920 12 19994 zwarich 2008-03-23 21:32:59 -0700 Created attachment 19994 Test for user navigation Here is a test case for what happens when a user navigates inside of an object element to content with application/x-unknown. Both Firefox and Opera prompt the user for a download, but my fix disables it entirely, displaying the fallback content instead. Should we match their behaviour? 75138 13 zwarich 2008-03-25 11:35:21 -0700 I've been talking with brady about this bug over IRC, and I just wanted to make a summary. Here are the scenarios: Scenario #1 - data of object element refers to application/x-unknown content WebKit (with Safari) - download and display fallback content Firefox and Opera - don't download and display fallback content Scenario #2 - application/x-unknown content reached via navigation inside of an object element WebKit (with Safari) - download and display fallback content Firefox and Opera - download and don't display fallback content Scenario #3 - src of iframe element refers to application/x-unknown content WebKit (with Safari) - download Firefox and Opera - download Scenario #4 - application/x-unknown content reached via navigation inside of an iframe element WebKit (with Safari) - download Firefox and Opera - download Note that we only differ on #1 and #2. 75139 14 beidson 2008-03-25 11:44:49 -0700 > Here are the scenarios: > Scenario #1 - data of object element refers to application/x-unknown content > > WebKit (with Safari) - download and display fallback content > Firefox and Opera - don't download and display fallback content The only difference here is app-level. Firefox and Opera prompt on downloads, but Safari downloads without prompting. Safari is the WebKit PolicyDelegate in this context and makes the download decision. If different behavior is desired, a Safari bug should be filed at http://bugreporter.apple.com > Scenario #2 - application/x-unknown content reached via navigation inside of an > object element > > WebKit (with Safari) - download and display fallback content > Firefox and Opera - download and don't display fallback content This is the interesting difference - and I'm having a hard time wrapping my head around why it is we're wrong and Opera/FFX are right. Can someone explain to me why we shouldn't display the fallback content? The "downloading the resource" bug popped up with Acid2, but does it cause us to fail anything? 75140 15 zwarich 2008-03-25 11:50:00 -0700 (In reply to comment #14) > > Scenario #2 - application/x-unknown content reached via navigation inside of an > > object element > > > > WebKit (with Safari) - download and display fallback content > > Firefox and Opera - download and don't display fallback content > > This is the interesting difference - and I'm having a hard time wrapping my > head around why it is we're wrong and Opera/FFX are right. Can someone explain > to me why we shouldn't display the fallback content? I think the idea is that if the page inside of the object element were the main document, you would still see the page after the download, so why not inside of the object element? I am not sure if this argument is really correct. It seems that either way you have to introduce some inconsistencies. > The "downloading the resource" bug popped up with Acid2, but does it cause us > to fail anything? It doesn't cause a failure with Acid 2, although some people would definitely see it as a problem. 86163 16 webkit 2008-07-16 23:40:16 -0700 (In reply to comment #14) > > Here are the scenarios: > > Scenario #1 - data of object element refers to application/x-unknown content > > > > WebKit (with Safari) - download and display fallback content > > Firefox and Opera - don't download and display fallback content > > The only difference here is app-level. Firefox and Opera prompt on downloads, > but Safari downloads without prompting. Safari is the WebKit PolicyDelegate in > this context and makes the download decision. If different behavior is > desired, a Safari bug should be filed at http://bugreporter.apple.com Brady, Firefox and Opera don't prompt for download on Acid2 (no data) page. This behavior is absolutely correct. Browsers shouldn't download nor prompt for download in this case. Only fallback content should be displayed as described in object handling algorithm: http://www.whatwg.org/specs/web-apps/current-work/#the-object. Cameron, do you plan to improve the patch? 19759 2008-03-14 04:49:10 -0700 2008-03-23 11:30:08 -0700 minimal test case test.html text/html 254 webkit PCFET0NUWVBFIGh0bWw+CjxvYmplY3QgZGF0YT0iaHR0cDovL2hpeGllLmNoL3Rlc3RzL2V2aWwv YWNpZC8wMDItbm8tZGF0YS9kYXRhMDA2Ij48b2JqZWN0IGRhdGE9Imh0dHA6Ly93d3cuZGFtb3dt b3cuY29tLzQwNC8iIHR5cGU9InRleHQvaHRtbCI+dGVzdDwvb2JqZWN0Pjwvb2JqZWN0Pgo8cD5X ZWJraXQgc2hvdWxkIE5PVCBkb3dubG9hZCBhbnkgZmlsZSAoZXNwZWNpYWxseSAwMDYgd2l0aCB0 ZXh0L2h0bWwgY29udGVudCB0eXBlKTwvcD4= 19979 2008-03-23 00:58:05 -0700 2008-03-23 00:58:05 -0700 Further reduction acid2data.html text/html 121 zwarich PGh0bWw+CjxoZWFkPgo8L2hlYWQ+Cjxib2R5Pgo8b2JqZWN0IGRhdGE9Imh0dHA6Ly9oaXhpZS5j aC90ZXN0cy9ldmlsL2FjaWQvMDAyLW5vLWRhdGEvZGF0YTAwNiI+PC9vYmplY3Q+CjwvYm9keT4K PC9odG1sPg== 19984 2008-03-23 11:58:18 -0700 2008-03-23 11:58:18 -0700 test case with data URI (ok) test case.html text/html 77 webkit PCFkb2N0eXBlIGh0bWw+CjxvYmplY3QgZGF0YT0iZGF0YTphcHBsaWNhdGlvbi94LXVua25vd24s RVJST1IiPnRlc3Q8L29iamVjdD4= 19993 2008-03-23 21:29:54 -0700 2010-06-10 15:46:23 -0700 Preliminary patch download.diff text/plain 836 zwarich SW5kZXg6IFdlYkNvcmUvbG9hZGVyL01haW5SZXNvdXJjZUxvYWRlci5jcHAKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gV2ViQ29yZS9sb2FkZXIvTWFpblJlc291cmNlTG9hZGVyLmNwcAkocmV2aXNpb24gMzEyMzkp CisrKyBXZWJDb3JlL2xvYWRlci9NYWluUmVzb3VyY2VMb2FkZXIuY3BwCSh3b3JraW5nIGNvcHkp CkBAIC0yMDEsOCArMjAxLDEyIEBAIHZvaWQgTWFpblJlc291cmNlTG9hZGVyOjpjb250aW51ZUFm dGVyQ28KICAgICB9CiAKICAgICBjYXNlIFBvbGljeURvd25sb2FkOgotICAgICAgICBmcmFtZUxv YWRlcigpLT5jbGllbnQoKS0+ZG93bmxvYWQobV9oYW5kbGUuZ2V0KCksIHJlcXVlc3QoKSwgbV9o YW5kbGUuZ2V0KCktPnJlcXVlc3QoKSwgcik7Ci0gICAgICAgIHJlY2VpdmVkRXJyb3IoaW50ZXJy dXB0aW9uRm9yUG9saWN5Q2hhbmdlRXJyb3IoKSk7CisgICAgICAgIGlmIChmcmFtZUxvYWRlcigp LT5pc0hvc3RlZEJ5T2JqZWN0RWxlbWVudCgpKQorICAgICAgICAgICAgc3RvcExvYWRpbmdGb3JQ b2xpY3lDaGFuZ2UoKTsKKyAgICAgICAgZWxzZSB7CisgICAgICAgICAgICBmcmFtZUxvYWRlcigp LT5jbGllbnQoKS0+ZG93bmxvYWQobV9oYW5kbGUuZ2V0KCksIHJlcXVlc3QoKSwgbV9oYW5kbGUu Z2V0KCktPnJlcXVlc3QoKSwgcik7CisgICAgICAgICAgICByZWNlaXZlZEVycm9yKGludGVycnVw dGlvbkZvclBvbGljeUNoYW5nZUVycm9yKCkpOyAgICAgICAgICAgIAorICAgICAgICB9CiAgICAg ICAgIHJldHVybjsKIAogICAgIGNhc2UgUG9saWN5SWdub3JlOgo= 19994 2008-03-23 21:32:59 -0700 2008-03-23 21:32:59 -0700 Test for user navigation objectdownload.zip application/octet-stream 1539 zwarich UEsDBAoAAAAAADEAeDgAAAAAAAAAAAAAAAAPABAAb2JqZWN0ZG93bmxvYWQvVVgMAGIo50edJ+dH 9QH1AVBLAwQUAAgACABNAHg4AAAAAAAAAAAAAAAAGwAQAG9iamVjdGRvd25sb2FkL2NvbnRlbnQu aHRtbFVYDABxLudH0ifnR/UB9QEtzTsOhDAMhOGeUyB6mIhiCxRoOIlJvLJFeAis1XJ7HqKZr/vH i02py7wwxQu8Dks8LiiXjb9tIWZrA4j+lasgMN5tB/80gYJGOFeX81JGMsI9zn2Krk8aRg+6s28P z9sJUEsHCISE0xZhAAAAdAAAAFBLAwQKAAAAAADVA3g4AAAAAAAAAAAAAAAACQAQAF9fTUFDT1NY L1VYDABxLudHcS7nR/UB9QFQSwMECgAAAAAA1QN4OAAAAAAAAAAAAAAAABgAEABfX01BQ09TWC9v YmplY3Rkb3dubG9hZC9VWAwAcS7nR3Eu50f1AfUBUEsDBBQACAAIAE0AeDgAAAAAAAAAAAAAAAAm ABAAX19NQUNPU1gvb2JqZWN0ZG93bmxvYWQvLl9jb250ZW50Lmh0bWxVWAwAcS7nR9In50f1AfUB Y2AVY2dgYmDwTUxW8A9WiFCAApAYAycQGwFxBxCD+LsYiAKOISFBDCEW76A6ZgCxEpoSRoS4aHJ+ rl5uYnJRfm5iSWqxXnJiUWoJQzUXyBXJ+TmluXkKtgqm5tZggZzMvFQg18SaqxYAUEsHCOc2g2Zp AAAAugAAAFBLAwQUAAgACAA3A3g4AAAAAAAAAAAAAAAAGQAQAG9iamVjdGRvd25sb2FkL2luZGV4 Lmh0bWxVWAwAcS7nR0ot50f1AfUBs8koyc2x47LJSE1MAVL6UDopP6USSOUnZaUmlyikJJYk2iol 5+eVpOaV6IF0KNm5JebkJCUmZytAhW30IYpBhkB164PNBgBQSwcIKf6G90cAAABiAAAAUEsDBBQA CAAIADcDeDgAAAAAAAAAAAAAAAAkABAAX19NQUNPU1gvb2JqZWN0ZG93bmxvYWQvLl9pbmRleC5o dG1sVVgMAHEu50dKLedH9QH1AWNgFWNnYGJg8E1MVvAPVohQgAKQGAMnEBsBcQcQg/i7GIgCjiEh QQwhYpugOmYAsRKaEkaEuGhyfq5ebmJyUX5uYklqsV5yYlFqCUM1F8gVyfk5pbl5CrYKJibWYIGc zLxUENeaqxYAUEsHCNLhvrhoAAAAugAAAFBLAQIVAwoAAAAAADEAeDgAAAAAAAAAAAAAAAAPAAwA AAAAAAAAAEDtQQAAAABvYmplY3Rkb3dubG9hZC9VWAgAYijnR50n50dQSwECFQMUAAgACABNAHg4 hITTFmEAAAB0AAAAGwAMAAAAAAAAAABApIE9AAAAb2JqZWN0ZG93bmxvYWQvY29udGVudC5odG1s VVgIAHEu50fSJ+dHUEsBAhUDCgAAAAAA1QN4OAAAAAAAAAAAAAAAAAkADAAAAAAAAAAAQP1B9wAA AF9fTUFDT1NYL1VYCABxLudHcS7nR1BLAQIVAwoAAAAAANUDeDgAAAAAAAAAAAAAAAAYAAwAAAAA AAAAAED9QS4BAABfX01BQ09TWC9vYmplY3Rkb3dubG9hZC9VWAgAcS7nR3Eu50dQSwECFQMUAAgA CABNAHg45zaDZmkAAAC6AAAAJgAMAAAAAAAAAABApIF0AQAAX19NQUNPU1gvb2JqZWN0ZG93bmxv YWQvLl9jb250ZW50Lmh0bWxVWAgAcS7nR9In50dQSwECFQMUAAgACAA3A3g4Kf6G90cAAABiAAAA GQAMAAAAAAAAAABApIFBAgAAb2JqZWN0ZG93bmxvYWQvaW5kZXguaHRtbFVYCABxLudHSi3nR1BL AQIVAxQACAAIADcDeDjS4b64aAAAALoAAAAkAAwAAAAAAAAAAECkgd8CAABfX01BQ09TWC9vYmpl Y3Rkb3dubG9hZC8uX2luZGV4Lmh0bWxVWAgAcS7nR0ot50dQSwUGAAAAAAcABwBEAgAAqQMAAAAA