WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 55750
33971
Check base URI validity before using in SVGImageLoader::sourceURI
https://bugs.webkit.org/show_bug.cgi?id=33971
Summary
Check base URI validity before using in SVGImageLoader::sourceURI
Bryan Yeung
Reported
2010-01-21 13:55:55 PST
If the element has no baseURI, then the sourceURI method will use an invalidated KURL object.
Attachments
patch checks for URL validity before using
(1.05 KB, patch)
2010-01-21 14:00 PST
,
Bryan Yeung
darin
: review-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Bryan Yeung
Comment 1
2010-01-21 14:00:19 PST
Created
attachment 47145
[details]
patch checks for URL validity before using
Darin Adler
Comment 2
2010-01-21 14:22:17 PST
Comment on
attachment 47145
[details]
patch checks for URL validity before using The call to deprecatedParseURL needs to be on the attr value *before* invoking KURL at all. Making that change alone might fix the bug. Something like this: return KURL(element()->baseURI(), deprecatedParseURL(attr)); This bug needs a test case. review- for lack of a test case and because the fix is probably wrong.
Bryan Yeung
Comment 3
2010-01-22 11:35:58 PST
Darin: Thanks for taking the time to look at my patch, and sorry: I should have included a bit more context around this issue. I don't think that the code you suggest addresses the problem that I see: element()->baseURI() is an invalidated KURL object whenever the SVG element does not have an xml:base specified. The code works anyway, because the relative path is still available from the invalidated URL, but it seems dangerous/wrong to make use of invalidated objects. (I've created a separate bug to track this behaviour of KURL:
https://bugs.webkit.org/show_bug.cgi?id=34011
). Maybe I'm just misunderstanding what it means for a KURL to be invalidated? Further, all of the other subclasses of ImageLoader return the result of deprecatedParseURL. If you're suggesting that this is incorrect, it will presumably need to be fixed everywhere (and has been wrong for quite some time...since rev 36712 which introduced the sourceURI method). I completely agree about the test case: I'll update the patch in a bit to include a new layout test that has images with and without a base URI specified. Thanks again, Bryan
Bryan Yeung
Comment 4
2010-01-22 12:00:33 PST
Actually, it looks like the test case I was about to write already exists: LayoutTests/svg/W3C-SVG-1.1/struct-image-07-t.svg This tests image elements with and without an xml:base specified, and exercises both paths in my proposed change.
Cosmin Truta
Comment 5
2011-01-31 14:23:10 PST
The following comment currently exists in KURLGoogle.cpp: // When KURL encounters an error such that the URL is invalid and empty // (for example, resolving a relative URL on a non-hierarchical base), it // will produce an isNull URL, and calling setUtf8 will produce an empty // non-null URL. This is unlikely to affect anything, but we preserve this // just in case. It looks like this bug is caused by this behavior. More specifically, here is what's happening if base="" and relative="foo.svg": * KURLGooglePrivate::init assumes (incorrectly?) that url_util::ResolveRelative always sets &output, regardless whether it returns VALID or INVALID. * url_util::ResolveRelative only sets &output if url_canon::IsRelativeURL returns TRUE. * url_canon::IsRelativeURL returns FALSE: - IsRelativeURL does not allow relative URLs if the base scheme does not support it. - base="", therefore it has no scheme. While I agree that a URL composed from base="" and relative="foo.svg" is invalid, I think that the behavior of KURL to set output="foo.svg" is useful (in contrast with the behavior of KURLGooglePrivate to set output=""). In order to resolve this bug, KURLGooglePrivate must agree with KURL.
Cosmin Truta
Comment 6
2011-02-01 20:18:26 PST
The failing test that I mentioned in
comment #5
is listed in the Chromium issue 42465
http://code.google.com/p/chromium/issues/detail?id=42465
Fady Samuel
Comment 7
2011-03-07 12:48:42 PST
*** This bug has been marked as a duplicate of
bug 55750
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug