| Summary: | [GTK] After upgrading glib and glib-networking, resources with zero bytes are always identified as text/plain | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Carlos Alberto Lopez Perez <clopez> | ||||
| Component: | WebKitGTK | Assignee: | Claudio Saavedra <csaavedra> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, commit-queue, csaavedra, mcatanzaro | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=755795 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 170942 | ||||||
| Attachments: |
|
||||||
|
Description
Carlos Alberto Lopez Perez
2017-04-20 09:21:31 PDT
Expectations updated at https://trac.webkit.org/changeset/215556 (In reply to Carlos Alberto Lopez Perez from comment #1) > Expectations updated at https://trac.webkit.org/changeset/215556 ^^^ I mean at: http://trac.webkit.org/changeset/215561 I think this was broken by this commit https://git.gnome.org/browse/glib/commit/?id=202a9c3497e0c0b5789e533509dd8671617ae20c Before this commit the empty file check was done after the g_content_type_guess and only when guessing from path returned an uncertain result. Now the check is done before unconditionally, so there's no basename guess for empty files. Reading the comments in the GNOME bug it seems the change in behavior was accidental, but then they decided it was an improvement. I kind of agree that a zero size file with .png extension is not a png file (or any other extension). I bet this only affects unit tests, so we can work around the issue inside webkit, either patching glib to only check zero-sized files after guessing the content type form the filename if the result is uncertain, or using real files (small enough, but real) in the tests. (In reply to Carlos Garcia Campos from comment #4) > Reading the comments in the GNOME bug it seems the change in behavior was > accidental, but then they decided it was an improvement. I kind of agree > that a zero size file with .png extension is not a png file (or any other > extension). I bet this only affects unit tests, so we can work around the > issue inside webkit, either patching glib to only check zero-sized files > after guessing the content type form the filename if the result is > uncertain, or using real files (small enough, but real) in the tests. I wonder why this files are empty on our Layout tests. Is that intentional? Or it is a mistake nobody noticed so far? Looking at the git history of this file nothing seems to suggest that the files are empty on purpose. It looks like a mistake. Maybe we should replace the empty files with files valid for their supposed mime-type (for example, for a png file we can use a 1x1 transparent png). At the same time we can add a new test that loads several zero-byte resource files. This test should produce plain/text on glib based ports and other thing on the rest of ports. I guess they are empty because the actual contents doesn't really matter. So, making them valid for their mime type would be harmless, and would fix these tests for the glib based ports. I would vote for changing the tests to not use empty files. This is a silly reason to carry a downstream patch forever and it's not advantageous for our tests to exhibit special behavior that never occurs in releases. Created attachment 309888 [details]
Patch
Comment on attachment 309888 [details]
Patch
Thanks!
Comment on attachment 309888 [details] Patch Clearing flags on attachment: 309888 Committed r216762: <http://trac.webkit.org/changeset/216762> All reviewed patches have been landed. Closing bug. |