3.87 KB, text/plain
TESTCASE: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1877 Change the timeout from 0ms to a higher number, and observe that there's a cut-off beyond which the base URL change no longer takes effect, which is significantly higher than 0ms. From: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17005
Is this significantly worse or different on OS X? Or should it be marked Platform : All?
Bug 767631 is the culprit here -- we don't re-trigger the load of the object when many things change (including base URI) even though we should. The reason the new base URL seems to take effect below a certain timeout is because we "notice" the baseURI changed when the initial channel OnStartRequest arrives (We call OnStartRequest->LoadObject->UpdateObjectParameters ). After that event has happened, nothing else properly re-calls nsObjectLoadingContent::LoadObject() :(  http://dxr.mozilla.org/mozilla-central/content/base/src/nsObjectLoadingContent.cpp#l1637
Assignee: nobody → jschoenick
Depends on: 767631
OS: Mac OS X → All
Hardware: x86 → All
Created attachment 732095 [details] nsObjectLoadingContent debug log showing what's happening FWIW running with NSPR_LOG_MODULES="objlc:5" makes it easier to trace <object> tag's crazy decision making. Annotated log attached.
Note that per the spec, you shouldn't react to the base URI changing at all.
(In reply to Hixie (not reading bugmail) from comment #4) > Note that per the spec, you shouldn't react to the base URI changing at all. You're right. In that case, we need to just not check plugin parameters from non-explicit LoadObject() calls, such as from OnStartRequest.
Status: NEW → ASSIGNED
No longer depends on: 767631
You need to log in before you can comment on or make changes to this bug.