Closed Bug 507182 Opened 12 years ago Closed 4 years ago

Plugins' state is lost when navigating in backward/forward cache


(Core :: Plug-ins, defect)

1.9.1 Branch
Windows XP
Not set





(Reporter: kbrussel, Unassigned)


There is a regression in the backward/forward cache in Firefox 3.5 affecting pages containing plugins. It appears that the cache is more aggressively caching page state (DOM + JavaScript state) in Firefox 3.5 compared to Firefox 3.0. However, plugin instances on the page are destroyed when placed in the cache and recreated when fetched from the cache. This means that plugins which have state that depends on JavaScript execution on the page have the wrong state when the page is fetched from the cache.

This problem has been reproduced on Windows XP and Vista, but I believe should affect all platforms.

To reproduce this problem, do the following:

1. Install the O3D plugin from .

2. Navigate to a simple example like .

3. Type a URL into the address bar, such as .

4. Use the "back" button to navigate back to the O3D example.

With Firefox 3.0, the O3D example will render correctly because the JavaScript on the page is re-run. With Firefox 3.5, the O3D area will be blank because the JavaScript on the page is not re-run.
OK, I just tested this on Mac with clean profiles, and in Firefox 3.0 (debug build) I see us restoring the helloworld page in question from bfcache.  In particular, after going back to it the plug-in doesn't work correctly.

Again, this is in 3.0.  So I don't see a regression here...
Please try on Windows. There is definitely a regression on that platform.
Same thing on Windows with Firefox 3.0.12 and 3.0.10 releases.  Testing methodology:

1) Start browser
2) Load
3) Make sure plug-in instantiates and shows the teapot
4) Put


   in the url bar.
5) Hit enter
6) Note that "x" appears after the plug-in in the document.
7) Type "about:blank" in the url bar.
8) Hit enter.
9) Click the back button in the toolbar.
10) Note that the "x" is present after the plug-in (indicating that the load
    was from bfcache) and that the plug-in is not showing the teapot.
OK, I now see this behavior. We have one Windows laptop here running Firefox 3.0.12 which always reloads the page from the URL when going back in the history. However, I've confirmed that on multiple other Windows machines, and as far back as Firefox, the back/forward cache works in the way described above, and the O3D plugin instance is blank upon navigating back to it.

Since this isn't a regression in Firefox 3.5 I've updated the synopsis.

IE, Chrome and Safari 4 on Windows work properly in this scenario; they reload the page each time. Opera 10 beta 2 behaves similarly to Firefox.

This seems to be a big semantic problem with no obvious good solution. One could consider adding pause/resume APIs to the NPAPI. A co-worker points out, however, that there is no guarantee that they could work. For example, the plugin might be streaming some content from a server using a protocol that didn't support resumption, or it might be using an authentication cookie that might expire before the plugin instance was resumed. Also, paused plugins could consume large amounts of memory.

One could consider reloading pages from their source URL if they contain plugins, rather than using the contents of the b/f cache. This seems unworkable given the widespread use of Flash in ads.

One could consider adding new events to the DOM; something like "window.onreload". This could take a very long time to specify and gain widespread user agent support.

Do others have comments or suggestions on how this problem could be solved?
Summary: Regression in handling of plugins in backward/forward cache in Firefox 3.5 → Plugins' state is lost when navigating in backward/forward cache
(In reply to comment #4)
> One could consider adding new events to the DOM; something like
> "window.onreload". This could take a very long time to specify and gain
> widespread user agent support.

Those events have existed in Firefox since version 1.5 --- pageshow/pagehide.
Thanks for those pointers and sorry for my ignorance. I think they provide a suitable workaround.

beisi pointed out that implementing this is basically the same as . I'll close this as a duplicate of the other one.
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 90268
It's not quite a duplicate, since we'd still need to pause when going into bfcache, no?  That is, we'd still have to kill the plug-in when going into bfcache, even with that bug fixed.

I think a pause NPAPI extension that lets the plug-in say "no, can't" (and then we wouldn't bfcache the page) is the way to go here.
Resolution: DUPLICATE → ---
Severity: major → normal
Closed: 12 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.