All users were logged out of Bugzilla on October 13th, 2018

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

RESOLVED INVALID

Status

()

RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: int3, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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

7 years ago
Do you have a testcase demonstrating this problem?

Comment 2

7 years ago
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

7 years ago
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

Comment 4

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

Comment 5

7 years ago
Perhaps we could have message.target = null?
(Reporter)

Comment 6

7 years ago
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

7 years ago
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
(Reporter)

Comment 8

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

Comment 9

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

Comment 10

7 years ago
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.
(Reporter)

Comment 12

7 years ago
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.