If we rescan plugins to update the plugin list not through JavaScript, we should instruct DOM to refresh its list too. The following steps can show what this bug results in: 1. have Flash plugin absent somehow 2. start browser, in about:plugins there should be no Flash 3. add Flash plugin to the Plugins folder 4. go to a page which requires the plugin, this will cause plugin rescan 5. the plugin should be picked up and work fine 6. load about:plugins, it is not there Expected: it should be listed in the about:plugins page.

This is a regression caused by patch from bug 144058 which got incorporated to a bigger patch from bug 143178. If we reload plugins internally, not via JavaScript, DOM arrays don't change and when the time comes DOM does not know that plugins have changed and reports the old array.

setting milestone

Is not this array supposed to be recreated for each document and on reload?

Hmm, window.navigator (NavigatorImpl) owns the plugin array, and window.navigator (the native object) is re-used within a window, so the plugin array would not be re-created when loading a new document or reloading a document. This is fixable by releasing mNavigator in GlobalWindowImpl::SetNewDocument().

*** Bug 152457 has been marked as a duplicate of this bug. ***

Not sure if this is the optimal way to fix this bug, but here's a patch that resets the navigator object and in turn resets the plugins and mime types array on page load. Reloading or re-visting the page now works.

Comment on attachment 88478 [details] [diff] [review] patch to reset navigator object on page page load sr=jst

Comment on attachment 88478 [details] [diff] [review] patch to reset navigator object on page page load Confirm that this fixes the bug, r=av

patch in turnk, marking FIXED

nominating, this is important to get plugin detection correct.

adding ADT impact: note the DOM is not refreshed, consequently the DOM will be out of sync -- and that can cause unexpected results. As explained here, the About plugins page will get out of sync with what has really been installed, if that happens the user experience could be they end up being asked to reinstall the plug-in they just installed.

I verify that the problem is now fixed on today trunk build.

I should've caught this when sr'ing, but I didn't :-( Well, better late than never...

The original patch in this bug does fix the problem reported here, but it leaves a potential crash bihind... The new patch fixes that potential crash. Reopening to get this potential crash fixed too.

Comment on attachment 89346 [details] [diff] [review] We also need to null out the docshell ptr in the navigator object! r=sicking

Comment on attachment 89346 [details] [diff] [review] We also need to null out the docshell ptr in the navigator object! sr=alecf

Fix checked in.

Shrir, can you verify this fix on the trunk. Thx.

verified on trunk 0627. works fine.

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending drivers approval. pls check this in asap, then add the "fixed1.0.1" keyword.

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

On the branch now.

verified on branch 0823, this works now.

*** Bug 85488 has been marked as a duplicate of this bug. ***