[Webkit-unassigned] [Bug 32706] <noscript> is taking effect even though the Javascript is enabled, when XHTMLMP is enabled

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Dec 24 06:50:06 PST 2009


https://bugs.webkit.org/show_bug.cgi?id=32706





--- Comment #11 from Charles Wei <charles.wei at torchmobile.com.cn>  2009-12-24 06:50:06 PST ---

> I am unclear from your snippet whether this is a valid XHTML-MP document and
> whether this document would or should be interpreted as being an XHTML-MP
> document. I mean, it's missing a DOCTYPE and an xml namespace. So, how does the
> browser know to interpret this as XHTML-MP? by file extension? by MIME type
> "application/vnd.wap.xhtml+xml"? when XHTML-MP is enabled in WebKit do we just
> interpret all documents as XHTML-MP? some combination?
> 
> (I briefly looked through some of the XHTML-MP code, and from my understanding,
> it looks for the DOCTYPE and xml namespace declarations as well as accepts the
> MIME type "application/vnd.wap.xhtml+xml".)
> 
> I would suggest only using the XHTML-MP logic when we clearly know that the
> document we received is an XHTML-MP document since by the HTML 5 spec.
> <noscript> has a precisely defined behavior under HTML, but has no meaning
> under XHTML (*). Hence, the expected result of interpreting your example as
> XHTML should be a redirect (regardless of whether JavaScript is enabled). And
> the expected result of interpreting the document as HTML with JavaScript
> enabled is no redirect.
> 
> Assuming JavaScript is enabled, then interpreting your example as an XHTML-MP
> document should not cause a redirect. But, consider the slightly modified
> example:
> 
> <html>
>  <script type="unsupported-script-lang">...</script>
>  <noscript>
>      <meta http-equiv=refresh content="0; URL=http://www.google.com" />
>  </noscript>
> 
>  <body>
>      If you see this text and not re-directed to google when your browser is
>  Javascript enabled, it succeeds,  otherwise it fails .
>  </body>
> </html>
> 
> Assume JavaScript is enabled and suppose this is interpreted as being an
> XHTML-MP document. Then by section 9.2.1.2 of the XHTML-MP 1.1
> spec.<http://www.openmobilealliance.org/Technical/release_program/docs/Browsing/V2_2-20061020-A/OMA-WAP-XHTMLMP-V1_1-20061020-A.pdf>,
> we must process the <noscript> since we first encountered a <script> with an
> unsupported scripting language (i.e. "unsupported-script-lang"). So, the
> expected result is a redirect.
> 
> (*) Section 4.3.2 of the HTML 5 spec. states "...the noscript element is
> handled differently by the HTML parser based on whether scripting was enabled
> or not when the parser was invoked....The noscript element is only effective in
> the HTML syntax, it has no effect in the XHTML syntax"
> (http://dev.w3.org/html5/spec/Overview.html#the-noscript-element).


Thanks, Daniel,  for the comment. 

This bug is introduced by XHTML-MP for HTML document -- when XHTML-MP is
enabled, it's causing regressions for HTML documents , and that's what my patch
tries to fix.

When XHTML-MP is enabled,  it still distinguishes XHTML-MP document and HTML
documents, and uses different parsers for different documents.  The documents
will be distinguished by MIME type /file extension.  You are right that we
should only use XHTML-MP logic when we know that the document IS a XHTML-MP 
document. 

The problem is,  when the author of XHTML-MP introduced this feature to WebKit,
it causes regressions to HTML document by disabling some code of HTMLParser
with :

#if !ENABLE(XHTMLMP)
  original HTMLParser  code for <noscript> processing
#endif

That causes problems with <noscript> processing for HTML documents -- contents
inside <noscript> are always parsed and processed no matter Javascript is
enabled or not, which is incorrect for HTML document. 

That's my patch tries to fix -- to make contents inside <noscript> ignored when
Javascript is enabled for HTML document. 

Hope this makes it clear .

Thanks

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list