window.performance is null in a webpage loaded via <object>

RESOLVED FIXED in mozilla11

Status

()

Core
Document Navigation
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bz, Assigned: Igor Bazarny)

Tracking

unspecified
mozilla11
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

The problem is that we end up in nsDocShell::OnStateChange with this callstack:

#0  nsDocShell::OnStateChange (this=0x119b82400, aProgress=0x119b82428, aRequest=0x118bd5058, aStateFlags=983041, aStatus=0) at ../../../mozilla/docshell/base/nsDocShell.cpp:5896
...
#5  0x0000000101ccd28b in nsLoadGroup::AddRequest (this=0x118b6c830, request=0x118bd5058, ctxt=0x0) at ../../../../mozilla/netwerk/base/src/nsLoadGroup.cpp:615
#6  0x0000000102dba858 in nsURILoader::OpenChannel (this=0x119d46200, channel=0x118bd5058, aFlags=2, aWindowContext=0x119b82430, aChannelIsOpen=true, aListener=0x11b055148) at ../../../mozilla/uriloader/base/nsURILoader.cpp:910
#7  0x0000000102dba9fc in nsURILoader::OpenChannel (this=0x119d46200, channel=0x118bd5058, aFlags=2, aWindowContext=0x119b82430, aListener=0x11b055148) at ../../../mozilla/uriloader/base/nsURILoader.cpp:936
#8  0x00000001023a0128 in nsObjectLoadingContent::OnStartRequest (this=0x11b0550e0, aRequest=0x118bd5058, aContext=0x0) at ../../../../mozilla/content/base/src/nsObjectLoadingContent.cpp:687

and at this point mLoadType == 0, so we skip the MaybeInitTiming call.

Why do we have this mLoadType check anyway?
Ideally, we would just set mLoadType to LOAD_NORMAL somehow before making the OpenChannel call here, right?  Olli?

Comment 2

6 years ago
Sounds right.
So wait.  I still don't understand why this mLoadType check is there.  (Also, let's ignore the fact that treating STATE_START in the subdocshell there as a navigation start is bogus for <object>.).

Why can't we just unconditionally MaybeInitTiming()?
(Assignee)

Comment 4

6 years ago
Some tests which loaded xml (non-html) content via object tag got broken (crashed IIRC), there's indirect reference to that problem in comment 92 to issue 570341 https://bugzilla.mozilla.org/show_bug.cgi?id=570341#c92. There was some issue down the line with mLoadType needed to derive navigation type. And load type was not set up for objects.
Related: https://bugzilla.mozilla.org/show_bug.cgi?id=666897
> Some tests which loaded xml (non-html) content via object tag got broken

Was the issue just that mNavigationStartTimeStamp never got initialized and then you hit asserts about that?  That presumably needs to be addressed even if mLoadType is set to something nonzero.

> There was some issue down the line with mLoadType needed to derive navigation type

That code could just map 0 to LOAD_NORMAL if desired.

> And load type was not set up for objects.

Yes, which means that .performance is just broken in <object>, hence this bug...
(Assignee)

Comment 6

6 years ago
Created attachment 571634 [details] [diff] [review]
Assume LOAD_NORMAL if load type is not set for NavigationTiming nav type


Not sure whether I can peek into <object> and don't have much time right now. so patch includes just fix in navigation timing that lets it collect data if mLoadType was not initialized which is the case for object tag. Related W3C tests now pass
Comment on attachment 571634 [details] [diff] [review]
Assume LOAD_NORMAL if load type is not set for NavigationTiming nav type

Do you really mean to have two NotifyFetchStart calls there, one conditioned on this == aProgress and one not?  Looks like some sort of merge fail...
Igor, are you actively working on this?  If not, should I just take this?  This bug is causing us to fail most of the W3C navigation timing test suite....
(Assignee)

Comment 9

6 years ago
Created attachment 574879 [details] [diff] [review]
Collect timing data when load type is not initialized (assume LOAD_NORMAL)

Sorry for the delay, was distracted by other things.

Not sure this is the best way to go, I don't have enough expertise to look into the <object> loading code and make sure that load type is set there.
Attachment #574879 - Flags: review?(bzbarsky)
Comment on attachment 574879 [details] [diff] [review]
Collect timing data when load type is not initialized (assume LOAD_NORMAL)

I think this is the right approach.  Getting data from the object loading code to here is pretty hard...
Attachment #574879 - Flags: review?(bzbarsky) → review+
Oh, this needs a testcase, but I guess I can just write one....
(Assignee)

Comment 12

6 years ago
Thanks, I don't have experience writing tests for <object> tags.
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0f41e430ac0
Assignee: nobody → igor.bazarny
Flags: in-testsuite+
Target Milestone: --- → mozilla11
https://hg.mozilla.org/mozilla-central/rev/e0f41e430ac0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Attachment #571634 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.