All users were logged out of Bugzilla on October 13th, 2018
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.
Do you have a testcase demonstrating this problem?
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?
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?
Component: IPC → DOM
QA Contact: ipc → general
The unload event is for the tab going away (so this is not about the web pages' unload events).
Perhaps we could have message.target = null?
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.
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.
Component: DOM → IPC
That's fine, too, so long as there's a way to get the message safely across.
It should be possible to use process message manager in unload already now.
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.