1799935 - [Onboarding Video] - Permission denied to access property "ownerDocument" on reload

Status: RESOLVED FIXED

(Core :: XPConnect, defect, P1)

Description

[Punam Dahiya [:pdahiya]]

1. In latest Nightly, update pref browser.about.screens with value from gist https://gist.githubusercontent.com/punamdahiya/2eef4367d50fb4f4e108d8782f4f3ff3/raw/13454ccf8ef2f3d0f78b36614d9a438c8eb888c8/onboarding-video-2-screen-pref-value

2. Restart Nightly and open about:welcome , that loads video as first screen on about:welcome

3. Hit Reload shows below error in browser console ( select multiprocess browser console mode ) and fails to recover video play

Error: Permission denied to access property "ownerDocument"

https://searchfox.org/mozilla-central/rev/185db4a5f794fa6afbbd446944bdeaf640ba7d72/toolkit/content/widgets/videocontrols.js#19

Comment 1

[Punam Dahiya [:pdahiya]]

Attachment: Error in browser console

Comment 2

[Punam Dahiya [:pdahiya]]

Attachment: Screen of video screen with hang video

Comment 3

[Shane Hughes [:aminomancer]]

URL seems not to matter, even with a local video or empty src it still throws. about:welcome origin attributes or load flags probably need to be changed somehow? I guess this is an issue we just never encountered bc we haven't loaded videos in about pages before

Comment 4

[Punam Dahiya [:pdahiya]]

This could be blocker for Onboarding Video experiment and possible uplift candidate depending on complexity of fix.

Comment 5

[Punam Dahiya [:pdahiya]]

NI mconley to help provide feedback on Permission denied to access property "ownerDocument" error seen in videocontrols.js thanks!

https://searchfox.org/mozilla-central/rev/185db4a5f794fa6afbbd446944bdeaf640ba7d72/toolkit/content/widgets/videocontrols.js#19

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Hm... this is pretty bizarre. For some reason, after reloading the document, the UAWidget scope doesn't seem to have the permissions to access information about what the UA Widget is binding to (the <video> element in this case).

Hey nika, would you happen to know who on the DOM team might be able to help us with a UAWidget sandbox issue? Or would that be more of a SpiderMonkey thing?

Comment 7

[Emily McMinn :emcminn]

I did notice while I was debugging that the VideoControls widget implementation is refreshed, but not reloaded completely, on reload. The ShadowRoot that it gets attached to looks like it gets destroyed, and might not be recreated in time? (I did see some "undead object" flags when stepping through with the debugger.)
https://searchfox.org/mozilla-central/rev/185db4a5f794fa6afbbd446944bdeaf640ba7d72/toolkit/content/widgets/videocontrols.js#76

Comment 8

[Nika Layzell [:nika] (ni? for response)]

I don't know much about this sort of anonymous root stuff, but :smaug might be more familiar?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

I tried to reproduce this but having browser.about.screens string pref with gist as the value doesn't enable the video.
Is the pref name correct or did I use wrong value? (or is this perhaps not supported on Linux?)

Comment 10

[Shane Hughes [:aminomancer]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #9)

I tried to reproduce this but having browser.about.screens string pref with gist as the value doesn't enable the video.
Is the pref name correct or did I use wrong value? (or is this perhaps not supported on Linux?)

Oh the pref is actually browser.aboutwelcome.screens. Try this, it's working for me on ubuntu:

./mach run --temp-profile --setpref browser.aboutwelcome.screens='[{"id":"VIDEO_ONBOARDING","content":{"position":"center","title":"Thanks for downloading Firefox!","subtitle":"You’re contributing to a more open and accessible internet","has_noodles":false,"secondary_button":{"label":"Skip video","action":{"navigate":true}},"video_start":{"action":{}},"video_end":{"action":{"navigate":true}},"video_container":{"video_url":"https://assets.mozilla.net/video/firefox-welcome/MozillaBetterTogether.mp4","autoPlay":true}}},{"id":"AW_GRATITUDE","content":{"position":"split","split_narrow_bkg_position":"-228px","image_alt_text":{"string_id":"mr2022-onboarding-gratitude-image-alt"},"background":"url(\"chrome://activity-stream/content/data/content/assets/mr-gratitude.svg\") var(--mr-secondary-position) no-repeat var(--mr-screen-background-color)","progress_bar":true,"logo":{},"title":{"string_id":"mr2022-onboarding-gratitude-title"},"subtitle":{"string_id":"mr2022-onboarding-gratitude-subtitle"},"primary_button":{"label":{"string_id":"mr2022-onboarding-gratitude-primary-button-label"},"action":{"type":"OPEN_FIREFOX_VIEW","navigate":true}},"secondary_button":{"label":{"string_id":"mr2022-onboarding-gratitude-secondary-button-label"},"action":{"navigate":true}}}}]'

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

about:welcome crashes in debug builds when the pref is set to that value, even without doing any reloads. That makes debugging this a bit harder.

#7 0x00007f45201e844b in nsContentSecurityUtils::AssertAboutPageHasCSP(mozilla::dom::Document*) (aDocument=0x7f44f5d9c800) at /home/smaug/mozilla/hg/mozilla-central/dom/security/nsContentSecurityUtils.cpp:1237
#8 0x00007f451cb02fd4 in mozilla::dom::Document::EndLoad() (this=0x7f44f5d9c800) at /home/smaug/mozilla/hg/mozilla-central/dom/base/Document.cpp:7978
#9 0x00007f4520c64e46 in mozilla::dom::XMLDocument::EndLoad() (this=0x7f44f5d9c800) at /home/smaug/mozilla/hg/mozilla-central/dom/xml/XMLDocument.cpp:294
#10 0x00007f4520c68954 in nsXMLContentSink::DidBuildModel(bool) (this=0x7f44f5d77000, aTerminated=false) at /home/smaug/mozilla/hg/mozilla-central/dom/xml/nsXMLContentSink.cpp:318
#11 0x00007f451bce8f3c in nsParser::DidBuildModel() (this=0x7f44f42c2740) at /home/smaug/mozilla/hg/mozilla-central/parser/htmlparser/nsParser.cpp:332
#12 0x00007f451bce9800 in nsParser::ResumeParse(bool, bool, bool) (this=0x7f44f42c2740, allowIteration=true, aIsFinalChunk=true, aCanInterrupt=true) at /home/smaug/mozilla/hg/mozilla-central/parser/htmlparser/nsParser.cpp:767
#13 0x00007f451bceb063 in nsParser::OnStopRequest(nsIRequest*, nsresult) (this=0x7f44f42c2740, request=0x7f45311ab608, status=nsresult::NS_OK) at /home/smaug/mozilla/hg/mozilla-central/parser/htmlparser/nsParser.cpp:1062
#14 0x00007f451ca56c37 in mozilla::dom::DOMParser::ParseFromStream(nsIInputStream*, nsTSubstring<char16_t> const&, int, mozilla::dom::SupportedType, mozilla::ErrorResult&)
(this=0x7f44f42b12e0, aStream=0x7f44f46beeb0, aCharset=..., aContentLength=5171, aType=mozilla::dom::SupportedType::Application_xml, aRv=...) at /home/smaug/mozilla/hg/mozilla-central/dom/base/DOMParser.cpp:234
#15 0x00007f451ca560ee in mozilla::dom::DOMParser::ParseFromString(nsTSubstring<char16_t> const&, mozilla::dom::SupportedType, mozilla::ErrorResult&)

(I think that stack was mentioned in some other about:welcome bug too. asking on Matrix/Slack)

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

The crash is bug 1801063

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

The issue here is that
https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/caps/ContentPrincipal.cpp#258 fails
We end up here https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/netwerk/base/nsNetUtil.cpp#2474

In chrome JS one can see the same effect with Services.scriptSecurityManager.checkSameOriginURI(Services.io.newURI("about:welcome"), Services.io.newURI("about:welcome"), false, false); That throws.

So when about:welcome is first time loaded, we create the scope for UAWidgets
https://searchfox.org/mozilla-central/rev/5a49163b7012ded5fa1c4da5aa4f8d3f7c85a5e7/toolkit/actors/UAWidgetsChild.jsm#130
There we pass the nodePrincipal of the web page, so it has about:welcome as uri and the expanded principal has that as its internal principal.
Then when reloading, we reuse the same process and the same UAWidget scope, which has the principal of the previous page and security checks compare to the principal of the new page, and since the principals don't have the same identity (pointer comparison), we end up doing url same origin comparison and it fails.
Reuse of the scope happens because of https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/js/xpconnect/src/XPCJSRuntime.cpp#3059 and that lookup succeeds because https://searchfox.org/mozilla-central/rev/fadd0a14d2a2724ee4733ef73970a2ddd457a43f/js/xpconnect/src/xpcprivate.h#584,587-590 isn't considering this case.

Comment 14

[Emily McMinn :emcminn]

We don't think this edge case will block the Onboarding Video experiments, but it would definitely block release of the feature if we decide to go ahead with it.

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

The very latest Nightly should have this fixed (as part of another bug). Please test and close this one if that is the case.
If not, I'd like to know new steps to reproduce.

Comment 16

[Emily McMinn :emcminn]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #15)

The very latest Nightly should have this fixed (as part of another bug). Please test and close this one if that is the case.
If not, I'd like to know new steps to reproduce.

I was able to verify that this is fixed in latest Nightly :) The video & video controls load and reload with no errors. Thanks!

Comment 17

[Mike Conley (:mconley) (:⚙️)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #15)

The very latest Nightly should have this fixed (as part of another bug). Please test and close this one if that is the case.
If not, I'd like to know new steps to reproduce.

Great! What was the other bug, out of curiosity? (And for future bug historians)

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

bug 1802511 (it required some auditing, so private still)