Closed Bug 749652 Opened 9 years ago Closed 8 years ago

"TypeError: can't access dead object" when selecting items in the media list after closing the page

Categories

(Firefox :: Page Info Window, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 799329

People

(Reporter: dao, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

Opening Page Info, closing the page and selecting an item in the media list throws "TypeError: can't access dead object".
Maybe we should just close page info dialogs when their associated tabs are closed.
Duplicate of this bug: 757815
Ladies and Gentlemen,

as of Gavin's proposal I propose a patch (see attachment) that looks with the help of the WindowMediator for a document URI matching InfoWindow.

This works on my machine but when I start the browser, open the Error Console, open the Info Window, close the Browser Window (the Info Window closes and the Error Console is the only window open) the following error message appears:

Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized
Source File: resource://gre/modules/TelemetryStopwatch.jsm
Line: 53

Maybe anyone could guide us/me on the right way?
Simon thank you for your patch. Please read:
<https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F>
On how to format a patch properly. Essentially it has to be in git format.

Also you might like to read:
<https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch>
Philip,

I know, I should've read the rules first... my bad...

Okay, next try: patch in git format.
How this patch affect cases where two tabs are open with the same url?  (Web development is a common case of this.)  If one tab is closed, will it automatically close a page info window tied to another tab with the same url?
Assignee: nobody → sxw
Status: NEW → ASSIGNED
In addition this patch only runs on BrowserShutdown() so will miss all those background tabs.

Perhaps the page info window should maintain a tabprogress listener to the linked tab?
@Tanner: Well, that is the first problem, I already encountered -- doing the match just via the URL is, admitted, a quite suboptimal solution.  Maybe there is a possibility to access some kind of unique window ID that will only close the info window attached to that ID... I am going to investigate on that matter.

@Philip: Indeed. I also will have a look at that. I guess there is something similar like WindowMediator but for Tabs?
The PageInfo window maintains a link back to the originating window/tab via two variables:
gWindow and gDocument. I think it would be easier to put the logic in the PageInfo window itself. If either the window or document goes away then close the PageInfo window.
Are we better off fixing the Page Info window to work after the browser tab is closed by making it asynchronous or caching its data somewhere while Page Info is open rather than trying to close it when the tab closes?

I think it would be more useful to people to have Page Info able to function on its own at any time once the Page Info window has been opened.  For example, a web developer comparing different versions of his page as he is developing it will have more use from having the window remain open than if it unexpected closes or changes as he is working.  I believe there have been several recommendations for doing things like this already--like getting Page Info to gather media data asynchronously in stead of calling on the cache in ways that are now considered obsolete or unusual by some developers.

Perhaps if we resolve the larger question, this will go away automatically as part of that reshaping.

Granted, this is much simpler to fix than a total redesign of Page Info's data access and retention philosophy, and there is already a basic patch in Bugzilla where these discussions have been in the abstract.
Having the info window function without its underlying browser window would imply that a reference to the contents is saved within the info window, thus keeping the browser contents object from dying and the info window intact. Correct? Any other opinions/suggestion?
Err, no. The whole point of this bug is Bug 695480 cuts off all references to the content window forcibly when it goes away to prevent anything (like the Page Info) from holding on to it.
I have an onError handler email me a json blob every time there is a client side error on my site... maybe related?

{
  "message" : "TypeError: can't access dead object",
  "script" : "chrome://afterthedeadline/content/atd.js",
  "linenumber" : 687,
  "userAgent" : "Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Firefox/17.0"
}
Assignee: sxw → nobody
I'm going to dupe this forward, because the new bug is a bit cleaner and has a different proposed solution.
No longer blocks: hueyfix
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 799329
You need to log in before you can comment on or make changes to this bug.