856816 - <object> seems to wait around before resolving URL

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Hixie (not reading bugmail)]

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

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Is this significantly worse or different on OS X?  Or should it be marked Platform : All?

Comment 2

[John Schoenick [:johns]]

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 [1]). After that event has happened, nothing else properly re-calls nsObjectLoadingContent::LoadObject() :(

[1] http://dxr.mozilla.org/mozilla-central/content/base/src/nsObjectLoadingContent.cpp#l1637

Comment 3

[John Schoenick [:johns]]

Attachment: 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.

Comment 4

[Hixie (not reading bugmail)]

Note that per the spec, you shouldn't react to the base URI changing at all.

Comment 5

[John Schoenick [:johns]]

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

Comment 6

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.