673813 - Ensure content->chrome messages sent from the unload handler of the frame script get through

Status: RESOLVED INVALID

(Core :: IPC, defect)

Description

[Jez Ng [:int3]]

Right now, messages sent from the 'unload' event listener may not reach content before the messageManager gets destroyed. It would be very useful to have a guarantee that the message gets through; e.g., for data collection in the Session Restore service.

Comment 1

[Josh Matthews [:jdm]]

Do you have a testcase demonstrating this problem?

Comment 2

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

It is actually not clear to me how this all should work.
If chrome gets the message, should we somehow indicate that it cannot send
any async message back to content? Or should sendAsyncMessage throw some exception?

Comment 3

[Benjamin Smedberg]

The unload event listener does what? Informs you when an entire tab is going away, or when a particular page unloads?

If we're worried about the entire tab, note that we may choose to actually just kill the entire content process, so you should not keep precious data there anyway. But in that case, the chrome owner knows that the tab is going away, so it really doesn't matter, does it?

Comment 4

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

The unload event is for the tab going away (so this is not about the web pages' unload events).

Comment 5

[Jez Ng [:int3]]

Perhaps we could have message.target = null?

Comment 6

[Jez Ng [:int3]]

bsdmedberg: Session restore wants to collect the latest session data before the tab gets closed, and part of that data in stored in content. So while the chrome owner knows that the tab is going away, it cannot obtain the data immediately from the content process.

Comment 7

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

Hmm, this is tricky. When a window is closed, all the elements in
it can be unbound from document and the JS context is possibly deleted.
So the message managers in that window couldn't really do anything.

So, I think if frame script wants to send something to chrome when handling
unload event, it should do it using process message manager.

Comment 8

[Jez Ng [:int3]]

That's fine, too, so long as there's a way to get the message safely across.

Comment 9

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

It should be possible to use process message manager in unload already now.

Comment 10

[Benjamin Smedberg]

I still think there's a design issue here: the process message manager is not the correct layer to try and solve this problem.

Normally I would expect session restore data to just be sent regularly across, and you wouldn't need any special saving when a tab closes. But if for performance reasons you want to batch updates, I do this as part of the tab-closing process: before the tab actually goes away on the parent, send a message indicating that you want the final data, and delay actually closing the tab until it has been sent.

Comment 11

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

That is one possibility. Chrome would need to wait for some time before
closing a window so that it gets data from all the tabs.

Though, process mm is probably easier way, and if the data which the tab wants
to save is somehow global, and not really window specific, using
pmm is, IMO, the correct way.

Comment 12

[Jez Ng [:int3]]

The data we want to save is definitely tab-specific. I was actually considering giving the browsers some unique identifier so we could match them to their respective tabs even after unload.

Since it looks like there's no straightforward solution to this issue, I'm going to make session restore send updates on every input event for now -- we can profile the performance impact later.

Since this bug (with its specific feature request) can't be implemented, I'm going to resolve it as invalid.