| Summary: | Increase the set of script @type values that we treat as JavaScript | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ojan Vafai <ojan> | ||||||||
| Component: | WebCore JavaScript | Assignee: | Pablo Flouret <pf> | ||||||||
| Status: | RESOLVED DUPLICATE | ||||||||||
| Severity: | Normal | CC: | ahmad.saleem792, annevk, ap, barraclough, bfulgham, buildbot, dglazkov, odinho, ojan.autocc, oliver, pf, rniwa, syoichi, vitor.roriz, webkit-bug-importer, webkit.review.bot | ||||||||
| Priority: | P2 | Keywords: | EasyFix, InRadar | ||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=23097 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Ojan Vafai
2012-05-25 12:26:42 PDT
Do you intend to include "text/javascript;e4x=1", just to pick what seems like the most questionable item? (In reply to comment #1) > Do you intend to include "text/javascript;e4x=1", just to pick what seems like the most questionable item? I'm not actually intending on working on this, but I think we should either implement what's in the spec, or get the spec changed. I can't be bothered to spend my time arguing for either. In this specific case, the spec isolates this one as referring to "JavaScript with ECMAScript for XML", which is a language we don't support. But the rest refer to "JavaScript", which we do support. So, I think it'd be fine to leave this one out for WebKit without altering the spec. > So, I think it'd be fine to leave this one out for WebKit without altering the spec. Makes sense to me. See also: bug 23097, where our list of supported languages is already seen as too large. I don't have an opinion here FWIW. Created attachment 146979 [details]
Patch
Comment on attachment 146979 [details] Patch Attachment 146979 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12809033 New failing tests: fast/html/script-allowed-types-languages.html Created attachment 147025 [details]
Archive of layout-test-results from ec2-cr-linux-02
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Looks like this change should also be made in chrome's network stack. http://code.google.com/searchframe#OAMlx_jo-ck/src/net/base/mime_util.cc&l=328 Comment on attachment 146979 [details] Patch Attachment 146979 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://queues.webkit.org/results/15903868 New failing tests: fast/tokenizer/004.html Created attachment 184596 [details]
Patch for landing
(In reply to comment #9) > Created an attachment (id=184596) [details] > Patch for landing Fixed the tokenizer test and added failing expectations for chromium. Chromium bug: http://code.google.com/p/chromium/issues/detail?id=172076 Comment on attachment 184596 [details] Patch for landing Attachment 184596 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16112378 New failing tests: svg/batik/text/textLayout2.svg svg/batik/text/smallFonts.svg Comment on attachment 184596 [details]
Patch for landing
Test failures look unrelated.
I checked and this r+ patch didn't land yet. Is this needed anymore? Thanks! @Anne - I think you fixed similar bug to align WebKit with standard. Do we need this? *** This bug has been marked as a duplicate of bug 257080 *** |