[Webkit-unassigned] [Bug 43328] REGRESSION(61234): mail.139.com login fails

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 13 12:09:25 PDT 2010


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


Eric Seidel <eric at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at hixie.ch




--- Comment #25 from Eric Seidel <eric at webkit.org>  2010-09-13 12:09:25 PST ---
(In reply to comment #24)
> (From update of attachment 67447 [details])
> > +    // Some web pages assume that scheduled location changes abort parsing.
> > +    // The old HTML parser emulated this by polling the redirect scheduler
> > +    // every loop to see if it had scheduled a location change.  Instead we're
> > +    // stopping parsing if a location change is ever scheduled.
> > +    // FIXME: It's unclear if this is the right layer for this hack. It is
> > +    // possible that not all scheduled location changes should abort parsing.
> > +    if (DocumentParser* parser = m_frame->document()->parser())
> > +        parser->stopParsing();
> 
> What makes this a hack?

The hack part is due entirely to lack of specification.  There are at least 5 different places I could have conceivably put this code, each of which could have different behaviors exposed to the web.

For example:
1. in JSLocationCustom::setHref -- would work here, but wouldn't cover other possible location changes.
2.  Before or after security checks in JSLocationCustom?
3. Before or after null checks in JSLocationCustom?
4.  Inside the constructor to ScheduledLocation change?
5.  Inside the HTMLDocumentParser loop (this is how the old parser did it, but it didn't also check in end(), so it would have been possible in the old parser to restart parsing if the redirect failed and later bytes came off the network.  This seemed unintentional.)

> Is this something that should be documented in the HTML specification?

Yes.  I'm just not sure what the behavior should be.  This patch attempted to be simple, but making all scheduled location changes (from any source) abort parsing.

-- 
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