|
Description
Anne van Kesteren
2018-01-31 01:09:13 PST
Created attachment 356308 [details]
Patch
Comment on attachment 356308 [details] Patch Attachment 356308 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/10230910 New failing tests: imported/w3c/web-platform-tests/fetch/api/basic/scheme-data.any.worker.html Created attachment 356310 [details]
Archive of layout-test-results from ews100 for mac-sierra
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100 Port: mac-sierra Platform: Mac OS X 10.12.6
Comment on attachment 356308 [details] Patch Attachment 356308 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/10230926 New failing tests: imported/w3c/web-platform-tests/fetch/api/basic/scheme-data.any.worker.html Created attachment 356312 [details]
Archive of layout-test-results from ews106 for mac-sierra-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 356308 [details] Patch Attachment 356308 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/10231064 New failing tests: imported/w3c/web-platform-tests/fetch/api/basic/scheme-data.any.worker.html Created attachment 356314 [details]
Archive of layout-test-results from ews115 for mac-sierra
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115 Port: mac-sierra Platform: Mac OS X 10.12.6
Created attachment 356319 [details]
Patch
Created attachment 356335 [details]
Patch
Comment on attachment 356335 [details] Patch I think this is an obvious first step, but to make real progress bug 180526 needs to be improved/fixed, in order to do even better handling data URLs. Comment on attachment 356335 [details] Patch Attachment 356335 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10242062 New failing tests: imported/w3c/web-platform-tests/service-workers/service-worker/register-closed-window.https.html Created attachment 356348 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Created attachment 356359 [details]
Patch
Comment on attachment 356359 [details] Patch Attachment 356359 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10252148 New failing tests: imported/w3c/web-platform-tests/service-workers/service-worker/register-closed-window.https.html Created attachment 356404 [details]
Archive of layout-test-results from ews124 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Created attachment 356504 [details]
Patch
Comment on attachment 356504 [details]
Patch
Need to fix Changelog first.
Created attachment 356588 [details]
Patch
Comment on attachment 356588 [details] Patch Clearing flags on attachment: 356588 Committed r238890: <https://trac.webkit.org/changeset/238890> All reviewed patches have been landed. Closing bug. Reopening since there is more that needs fixing. Created attachment 360026 [details]
Patch
Comment on attachment 360026 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360026&action=review > Source/WebCore/platform/network/DataURLDecoder.cpp:53 > + if (!isValidContentType(mediaType)) > + return { "text/plain"_s, "US-ASCII"_s, "text/plain;charset=US-ASCII"_s, nullptr }; > + ParsedContentType parsedContentType(mediaType); This seems to parse the content type twice. Could we make a ParsedContentType::isValid instead? Hi Alex, yeah I realized the same thing. It is on my list, not sure if I should do it before or after this patch? (In reply to Rob Buis from comment #25) > Hi Alex, yeah I realized the same thing. It is on my list, not sure if I > should do it before or after this patch? Before or with this patch. Alternatively, you could make a static create function that returns Optional< ParsedContentType> (In reply to Alex Christensen from comment #27) > Alternatively, you could make a static create function that returns > Optional< ParsedContentType> I think that is less explicit, so I personally would prefer isValid. Anyway I'll make a patch tomorrow and we can always decide during review. Created attachment 360096 [details]
Patch
Comment on attachment 360096 [details] Patch Attachment 360096 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/10884973 New failing tests: imported/w3c/web-platform-tests/xhr/overridemimetype-blob.html Created attachment 360101 [details]
Archive of layout-test-results from ews103 for mac-highsierra
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-highsierra Platform: Mac OS X 10.13.6
Comment on attachment 360096 [details] Patch Attachment 360096 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/10885063 New failing tests: imported/w3c/web-platform-tests/xhr/overridemimetype-blob.html Created attachment 360102 [details]
Archive of layout-test-results from ews107 for mac-highsierra-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
Comment on attachment 360096 [details] Patch Attachment 360096 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/10884935 New failing tests: imported/w3c/web-platform-tests/xhr/overridemimetype-blob.html Created attachment 360104 [details]
Archive of layout-test-results from ews117 for mac-highsierra
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117 Port: mac-highsierra Platform: Mac OS X 10.13.6
Comment on attachment 360096 [details] Patch Attachment 360096 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: https://webkit-queues.webkit.org/results/10885195 New failing tests: imported/w3c/web-platform-tests/xhr/overridemimetype-blob.html Created attachment 360106 [details]
Archive of layout-test-results from ews123 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.13.6
Created attachment 360239 [details]
Patch
Is it ready for review? Comment on attachment 360239 [details]
Patch
What do the getters return if m_isValid is false? I think I prefer making a function that returns an Optional<ParsedContentType> rather than adding a bool and assuming all future users of this class will remember to check it. An Optional makes it syntactically required to check.
Created attachment 360365 [details]
Patch
Created attachment 360367 [details]
Patch
Created attachment 360370 [details]
Patch
(In reply to Alex Christensen from comment #40) > Comment on attachment 360239 [details] > Patch > > What do the getters return if m_isValid is false? I think I prefer making a > function that returns an Optional<ParsedContentType> rather than adding a > bool and assuming all future users of this class will remember to check it. > An Optional makes it syntactically required to check. Fair enough, I now went with this approach in my latest patch. Comment on attachment 360370 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=360370&action=review r=me > Source/WebCore/platform/network/ParsedContentType.cpp:188 > + if (m_contentType.contains('\r') || m_contentType.contains('\n')) These two checks could be done in one pass. Use this function in WTFString.h: size_t find(CodeUnitMatchFunction matchFunction, unsigned start = 0) > Source/WebCore/platform/network/ParsedContentType.cpp:289 > + return parsedContentType; I think this might unnecessarily copy parsedContentType and WTFMove(parsedContentType) might not, but I could be wrong. Please double check. Created attachment 360499 [details]
Patch
(In reply to Alex Christensen from comment #45) > Comment on attachment 360370 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=360370&action=review > > r=me > > > Source/WebCore/platform/network/ParsedContentType.cpp:188 > > + if (m_contentType.contains('\r') || m_contentType.contains('\n')) > > These two checks could be done in one pass. Use this function in WTFString.h: > size_t find(CodeUnitMatchFunction matchFunction, unsigned start = 0) Done. > > Source/WebCore/platform/network/ParsedContentType.cpp:289 > > + return parsedContentType; > > I think this might unnecessarily copy parsedContentType and > WTFMove(parsedContentType) might not, but I could be wrong. Please double > check. I checked, copy constructor was called indeed, so I added a move constructor and used WTFMove. Comment on attachment 360499 [details] Patch Clearing flags on attachment: 360499 Committed r240706: <https://trac.webkit.org/changeset/240706> All reviewed patches have been landed. Closing bug. Reopening to attach new patch. Created attachment 361798 [details]
Patch
Comment on attachment 361798 [details] Patch Attachment 361798 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/11123220 New failing tests: http/tests/inspector/network/resource-initiatorNode.html Created attachment 361806 [details]
Archive of layout-test-results from ews112 for mac-highsierra
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112 Port: mac-highsierra Platform: Mac OS X 10.13.6
Created attachment 361842 [details]
Patch
Comment on attachment 361842 [details] Patch Clearing flags on attachment: 361842 Committed r241333: <https://trac.webkit.org/changeset/241333> All reviewed patches have been landed. Closing bug. |