516749 - Electrolysis: prompts should be presented by the chrome process

Status: RESOLVED DUPLICATE of bug 548847

(Core :: IPC, defect)

Description

[Benjamin Smedberg]

Alerts and other prompts should be presented by the chrome process. They should, if at all possible, be associated with a particular IFrameEmbedding protocol so that the browser UI can present the prompt in context, instead of being app-modal or window-modal UI.

It would be good to catalog the exact set of prompts which may be posed by content: other than alert/confirm, most other dialogs such as network/SSL prompts can be handled entirely in chrome.

Comment 1

[Antoine Azar [:antoine]]

I can understand standard browser-generated messages to be displayed by the chrome, but do we really want content-generated messages (such as a javascript alert showing "Hello World") to be displayed by the chrome? That seems to break the concept of separation of chrome/content, and also adds a potential attack vector to crash the whole browser, if we're sending that "Hello World" string to the chrome process.

Comment 2

[Benjamin Smedberg]

Yes, we want content-generated messages to be displayed and controlled by chrome: so that it can provide suitable UI context, or so that it can control how they are displayed (tab-modal, perhaps).

Comment 3

[Boris Zbarsky [:bzbarsky]]

There's alert/confirm/prompt.

There's the dialog that comes up when onbeforeunload returns false.

There's showModalDialog, which involves a bit of chrome interaction.

There's print() and find().

I think that's about it.

I think Antoine's point is that it might be worth thinking about whether the actual renderers for the dialogs can live in the content process....

Comment 4

[Benjamin Smedberg]

I don't think they should... the actual behavior of the prompts depends on the app (the prompt in fennec are presented as transparent overlays, IIRC).

Comment 5

[Antoine Azar [:antoine]]

then we are accepting as a limitation that this is a potential vector for attacking the chrome process? Although I suppose there are a couple of those (history, session info, etc)?

Are these documented anywhere? It sounds like we should keep a log of all places content processes are allowed to send untrusted data to the chrome process, and perhaps build unit tests for those.

Comment 6

[Benjamin Smedberg]

What kind of "attack" are you talking about? It's sending a text string, not any sort of program. There are all kinds of places we'll be sending data from content to chrome for various reasons, and that's nothing special by itself.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Specifically, this allows attacks against the system text library (uniscribe, core text, etc) using particularly crafted sequences of characters and lengths.

We already have some mitigation for these sort of things in our font code; this would be a matter of someone finding a new vulnerability in one of these libraries.

Comment 8

[Benjamin Smedberg]

There are many places where the chrome process will retrieve content-controlled text, for display in the titlebar, tab titles, windows7 taskbar menu, etc.  We're not trying to implement complete data isolation.

Comment 9

[timeless]

arguably the file picker (save, open) dialogs are "prompts" which to some extent (more or less) are triggerable by content but should be managed by chrome.

to some extent, it should be possible to find these apis by reviewing the embedding apis for anything dialog related, because basically anything like that was something that embedders needed to change anyway.

Comment 10

[Antoine Azar [:antoine]]

Attachment: Work in progress patch - seeking input on whether the prompt should be modal or not, and how.

This is a work in progress patch.
Right now, we're locking the content process in an event loop waiting for the chrome to send back an IPDL message to unlock it. This IPDL message should be sent as soon as the prompt is dismissed.
Otherwise, we can keep the prompt modal in the chrome, making it app-modal and making the IPDL message sync, but we'll run into rendering grayed out on the content side.

Comment 11

[Benjamin Smedberg]

Dolske, sdwilsh says you're working on tab-modal alerts (in Fennec or Firefox?). This is probably intimately related and Antoine should coordinate with you.

Comment 12

[Justin Dolske [:Dolske]]

I haven't started working on tab-modal alerts/prompts, but it's something I really want to see fixed for about 1,000 different reasons. The UI we're calling doorhangers isn't really appropriate for this, so that's not a factor here.

The whole mess of nsIPrompt / nsIAuthPrompt flavors would be great to untangle as part of this (and I suspect it would be a requirement?). I got as far as starting to mapping the current stuff and thinking about how to replace it in https://wiki.mozilla.org/User:Dolske/PromptRework but set it aside for other things.

Comment 13

[Justin Dolske [:Dolske]]

[Note that tab-modal prompts is bug 59314, though there's just a bunch of comments there. There's almost certainly overlap here with bug 537782, because alert() and HTTP auth prompts share some common code (commonDialog.xul).]

Comment 14

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

Is this a dup of Bug 548847, or vice-versa?

Comment 15

[Benjamin Smedberg]

Yes.

Comment 16

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

Antoine, are you still working on this, since I'm actively hacking 
Bug 548847 (though currently trying a bit different approach).

Comment 17

[Antoine Azar [:antoine]]

Hey Olli, no, my work in progress patch I posted was the last I worked on this issue.