1631611 - Crash loading data: URI in a new tab

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect)

Description

[Matthew N. [:MattN]]

STR

1. Open a new tab with Command/Ctrl-T (the new tab page should be showing)
2. Paste data:text/html,Hello into the address bar and hit enter

Expected result:
"Hello" loads

Actual result:
Crash as seen in crash report bp-e2cfab2c-0526-4f32-b662-6a4f80200420.

Top 10 frames of crashing thread:

0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 XUL NS_DebugBreak xpcom/base/nsDebugImpl.cpp
2 XUL nsDebugImpl::Abort xpcom/base/nsDebugImpl.cpp:134
3 XUL NS_InvokeByIndex 
4 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1141
5 XUL XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:947
6 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:584
7 XUL Interpret js/src/vm/Interpreter.cpp:647
8 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:619
9 XUL JS_CallFunctionValue js/src/jsapi.cpp:2740

I suspect the cause is https://searchfox.org/mozilla-central/rev/d2cec90777d573585f8477d5170892e5dcdfb0ab/browser/components/newtab/AboutNewTabService.jsm#364,391

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Yes, I'm seeing the same and confirmed that that's the line of code involved.

Comment 2

[:Gijs (he/him)]

The stack here is... not helpful. (That is, I expect a bunch of these crashes are mis-attributed to this bug.)

Fixing this to not crash is easy (just remove the aborts!), though IMO we should make sure that principal inheriting links opened in the privileged content process open in a less privileged process instead... If that's not straightforward though, it might make sense to remove the abort and file a follow-up...

Comment 3

[Rob Lemley [:rjl]]

Attachment: Enable OpenPGP on platforms that are ready

Not the final configuration, just until win64 cross-compiled builds
are working.

Comment 4

[Matthew N. [:MattN]]

Comment on attachment 9141919 [details] [diff] [review]
Enable OpenPGP on platforms that are ready

I think you have the wrong bug number.

Comment 5

[Matthew N. [:MattN]]

(In reply to :Gijs (he/him) from comment #2)

The stack here is... not helpful. (That is, I expect a bunch of these crashes are mis-attributed to this bug.)

There are no recent ones before this crash but I know what you mean.

Comment 6

[Marco Zehe (:MarcoZ)]

I was seeing something similar over the weekend when testing on the Mac what data:text/html,<hr /> exposes to VoiceOver. The tab immediately crashed. See https://crash-stats.mozilla.org/report/index/ece4bcb6-b888-49d5-8b9a-a385a0200418

Comment 7

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

Attachment: Bug 1631611 - Use a JSWindowActorChild to load about:newtab scripts from the ScriptPreloader rather than an observer. r?pdahiya!

This shifts the responsibility for ensuring that an about:home, about:welcome
or about:newtab page is where we inject the scripts to the JSWindowActor system,
rather than using the observer service on document creation and checking the
URL.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f64c8c158e52
Use a JSWindowActorChild to load about:newtab scripts from the ScriptPreloader rather than an observer. r=pdahiya

Comment 9

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/f64c8c158e52

Comment 11

[Marius Coman [:mcoman], Ecosystem QA]

I have verified that this issue is no longer reproducible with the latest Firefox Nightly (77.0a1 Build ID - 20200428214747) installed, on Windows 10 x64, Ubuntu 18.04 x64 and Mac 10.15.3. I can confirm that the "Hello" string is successfully displayed after following the steps from the description.