Closed Bug 104360 Opened 23 years ago Closed 19 years ago

In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"; (When closing tabs with Site Navigation Bar showed)

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey1.0beta

People

(Reporter: bugzilla, Assigned: WeirdAl)

References

Details

(Keywords: fixed-seamonkey1.0, fixed1.8)

Attachments

(1 file, 1 obsolete file)

Whenever I close a browser tab: Error: this.docShell has no properties Source File: chrome://global/content/bindings/browser.xml#browser.webNavigation (getter) Line: 0 build 20011011
another way to reproduce: 1. go to http://gemal.dk/test/2.html 2. right click on the link there and say "open in new tab" 3. then you get en error saying that the page could not be loaded. 4. select the tab with the page the didn't load 5. select the View menuitem Error: this.docShell.contentViewer has no properties Source File: chrome://global/content/bindings/browser.xml#browser.markupDocumentViewer (getter) Line: 0
*** Bug 107113 has been marked as a duplicate of this bug. ***
->tabbed browser
Assignee: pchen → hyatt
Component: XP Apps → Tabbed Browser
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
still valid in 20020116 when closing a tab where you got the "host could not be found" alert
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
This has the same underlying problem as bug 104361.
Depends on: 104361
QA Contact: sairuh → pmac
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126" Bug still there: as described in report.
*** Bug 142401 has been marked as a duplicate of this bug. ***
Henrik, can you test this again? It works for me with 2003010505 on Win2k.
OTOH it might be our proxy that delivers a html page on such a "not found" error, so I *get* a page - in contrast to others. But with proxy off it still works. However, the error is different, so really somebody should try who previously could reproduce it. Sorry if it was false alarm...
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] In reply to comment 9 and 10: I don't know about newer builds, but with v1.3a: From Description: *It does happen, but after a failure (timeout) to access a site only; Then it happens on all/any tab closing, untill a new tab is open ! From comment 1: *Could not reproduce: What do you mean exactly by "select the View menuitem" ? *I tried clicking on View from the Window MenuBar, Viewing source, and Info.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312] Bug still there.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401] Bug still there. (with v1.3 profile, at least)
I suggest to change the summary to: In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"
*Target Milestone "mozilla1.1alpha" is way overdue...
Summary: javascript error in browser.xml → In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"; (On closing some tabs)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507] Bug still there. (with v1.3 (or v1.4a !?) profile, at least)
retargeting
Target Milestone: mozilla1.1alpha → Future
*** Bug 212020 has been marked as a duplicate of this bug. ***
Is bug 216580 a dupe of this one?
*** Bug 216580 has been marked as a duplicate of this bug. ***
Changing 'OS' from 'Windows 2000' to 'All', since bug 216580 report is about Linux.
OS: Windows 2000 → All
*** Bug 192386 has been marked as a duplicate of this bug. ***
*** Bug 240389 has been marked as a duplicate of this bug. ***
*** Bug 251572 has been marked as a duplicate of this bug. ***
I have seen this error reported in the js console hundreds and hundreds of times. I wish someone would *kill* that error for good.
Now WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Can anyone else reproduce it? Otherwise we could mark it as WFM.
I can't see the error message anymore, even after trying the steps to reproduce of comment #1. Mozilla 1.8a6 build 2004120405 and Firefox 1.0 final release build 20041107 rv:1.7.5 under XP Pro SP2 here. Resolving as WORKSFORME
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
WFM Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4) v.
Status: RESOLVED → VERIFIED
I'm seeing this error a lot, but tracked it down now to only when I have the "web developer" extensino enabled, not sure if this helps anyone.
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041122] (release) (W98SE) I confirm that comment 1 case do not show this bug anymore ! Yet, testing per (duplicated) bug 142401 comment 2 (see 4 and 7 too), still report {{ Error: this.docShell has no properties Source File: chrome://global/content/bindings/browser.xml Line: 0 }} on tab closing, and the site bar stays :-( Could someone test this other case with a Mozilla/1.8a6 nighly (and the FireFox/1.0 release) ?
> testing per (duplicated) bug 142401 comment 2 (see 4 and 7 too), > still report > {{ > Error: this.docShell has no properties > Source File: chrome://global/content/bindings/browser.xml > Line: 0 > }} > on tab closing, and the site bar stays :-( The Site Navigation toolbar still remains (I have "Show Only As Needed" checked) because bugzilla usually uses the Site Navigation toolbar. The js error is still reported when closing the tab. I'm reopening this bug. Setting dependency to bug 103053. Mozilla 1.8a6 build 2004121104 under XP Pro SP2 here.
Blocks: 103053
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Summary: In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"; (On closing some tabs) → In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"; (When closing tabs with Site Navigation Bar showed)
Whiteboard: [See comment 30 & 31 for remaining issue]
Error: this.docShell has no properties Source File: chrome://global/content/bindings/browser.xml Line: 0 still in Mozilla Firefox 20050418
another way to reproduce: 1) window.open('some_url','_blank','resizable=1'); 2) in opened window press CTRl+B or CTRL+H to open Bookmarks or History in sidebar 3) sidebar will NOT open and error 'this.docShell has no properties' will appear in JavaScript console P.S.: instead of 'resizable=1' can be any of window_open_option. There is NOT bug if window.open('some_url','_blank',''); Firefox 1.0.1 20050225
Found a way to reproduce this 100% of the time: 1) Clean Firefox install (or new profile) 2) Install Web Developer extension version 0.9.3 3) Install Sessionsaver 0.2 d1 nightly 27 (note: steps 2 and 3 can be switched) 4) Make sure those two extensions are installed and running (restart Firefox) 5) Create a new tab 6) Close it Web developer by itself won't trigger the bug. Neither will Sessionsaver. Both are needed to trigger the bug. What's most puzzling is that uninstalling Sessionsaver doesn't solve the problem - the bug is still there. So: install web developer, install sessionsaver, uninstall sessionsaver -> bug still exists. It requires uninstalling Web Developer to get rid of the bug, regardless of whether Sessionsaver is uninstalled. There are probably many other ways to reproduce this this.docshell bug - other combinations of extensions may trigger it. It seems to be an extension problem, not a Firefox one (or at least not directly a Firefox one).
You can REset javascript.options.showInConsole to false in about:config and that will make this (and other internal errors) do not show up any more.
(In reply to comment #35) > You can REset javascript.options.showInConsole to false in about:config and that > will make this (and other internal errors) do not show up any more. Sure ... but that doesn't help fixing the error(s), does it ?
No, not at all. But, what matters to me, this makes developing sites for firefox and using JavaScript console easier as it shows me only what I want to see (my errors). As end user, that is what I care about and I will take a risk and guess that this is the case with most of other people who visit this page.
(In reply to comment #37) > As end user, that is what I care about and I will take a risk and guess > that this is the case with most of other people who visit this page. The point is that (this) BugZilla page is *not* directed to end-user, but to MozillaAS & co developers...
When trying to reproduce this bug I got another line (not 0) where the error occured. It happens in '<property name="securityUI">' within '<setter>'. <setter> <![CDATA[ this.docShell.securityUI = val; ]]> </setter> Perhaps this will help to get closer to the issue.
Ok, I tested again with my developer trunk build and get following output: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "this.docShell has no properties" {file: "chrome://global/content/bindings/browser.xml" line: 0}]' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://global/content/bindings/tabbrowser.xml :: removeTab :: line 1201" data: yes] ************************************************************ ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529 ###!!! ASSERTION: no document: 'doc', file nsXULElement.cpp, line 2529 Break: at file nsXULElement.cpp, line 2529
I was able to reproduce this when closing a SeaMonkey trunk window with the sidebar open. I encountered it while playing with a patch for bug 312630. Steps to reproduce: (1) Launch SeaMonkey navigator window (2) Open sidebar (3) Close SeaMonkey navigator window With a little JS hackery, I found the following cause: JavaScript error: chrome://global/content/bindings/browser.xml, line 345: this.docShell has no properties set securityUI(): null Error("Hello World")@:0 set_securityUI(null)@chrome://global/content/bindings/browser.xml:340 destroy()@chrome://global/content/bindings/browser.xml:465 ()@chrome://global/content/bindings/browser.xml:447 @:0 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051016 SeaMonkey/1.1a The browser element is being destroyed, but there's no docShell available to it anymore. Patch coming right up.
Assignee: jag → ajvincent
Status: REOPENED → NEW
Attached patch patch (obsolete) — Splinter Review
Attachment #199761 - Flags: superreview?(bzbarsky)
Attachment #199761 - Flags: review?(bzbarsky)
Comment on attachment 199761 [details] [diff] [review] patch I'm not a peer for this module (so can't r=), last I checked. And I have no idea what this patch is currently doing and why....
Attachment #199761 - Flags: superreview?(bzbarsky)
Attachment #199761 - Flags: review?(bzbarsky)
Comment on attachment 199761 [details] [diff] [review] patch What this patch does is it checks to see if we have a docshell before trying to reference any of its properties. Because destroy() calls it, and destroy() is itself called by the destructor, it's a fairly safe bet. (Destroy, per the browser.xml file, is also called by tabbrowser when a tab goes away.)
Attachment #199761 - Flags: review?(neil.parkwaycc.co.uk)
In the case of the sidebar we have many <browser hidden="true"> elements which causes issues in the constructor as well but they're hidden by try/catch. bz, since nsDocShell::Destroy already nulls out mSecurityUI can we simply remove the offending line from browser.xml's destructor?
Er... yes... Did that not happen as part of bug 303839?
Comment on attachment 199761 [details] [diff] [review] patch (In reply to comment #46) > Er... yes... Did that not happen as part of bug 303839? Oh, I get it. :) They did it for toolkit, but they didn't do it for xpfe. New patch coming right up.
Attachment #199761 - Attachment is obsolete: true
Attachment #199761 - Flags: review?(neil.parkwaycc.co.uk)
This patch copies over the change to toolkit/.../browser.xml into xpfe/.../browser.xml.
Attachment #199798 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #199798 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #199798 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #199798 - Flags: superreview+
Attachment #199798 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #199798 - Flags: review+
checked into trunk
Status: NEW → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
I'm using nightly build of Firefox and I still get this: Error: this.docShell has no properties Source file: chrome://global/content/bindings/browser.xml could it be due to some extension?
gemal: I don't know. I don't usually build Firefox. If you can get flat chrome for that build, then I'd suggest doing what I did to find the source of the error. Specifically, wherever this.docShell is referenced in browser.xml, add a dump statement to see which one immediately precedes that error. When you've isolated it, add code like the following to that instance: try { throw new Error("Stack trace"); } catch (e) { dump e.stack; } I advise against using Venkman to try tracking this down, as there is a known crasher with Venkman and stacks (JS_ASSERT). You may want to file a new bug for any such instances, instead of reopening this one. I'd certainly appreciate a cc.
I've created Bug 313048 since I still see this issue in nightly builds of firefox
Moving to correct product so we can grant a=
Component: Tabbed Browser → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
Comment on attachment 199798 [details] [diff] [review] patch, v2 (Checked in trunk/branch 1.8 & 1.8.0) First a=me
Comment on attachment 199798 [details] [diff] [review] patch, v2 (Checked in trunk/branch 1.8 & 1.8.0) a=me for SM1.0b on SM only part of code, 2nd need one - Yay!
Attachment #199798 - Flags: approval-seamonkey1.0+
Target Milestone: Future → seamonkey1.0beta
Checked into 1.8 branch: /cvsroot/mozilla/xpfe/global/resources/content/bindings/browser.xml,v <-- browser.xml new revision: 1.40.2.2; previous revision: 1.40.2.1
Keywords: fixed1.8
Whiteboard: [See comment 30 & 31 for remaining issue] → [See comment 30 & 31 for remaining issue] fixed-seamonkey1.0
(In reply to comment #31) > > testing per (duplicated) bug 142401 comment 2 (see 4 and 7 too), V.Fixed, but I filed bug 320693 as a followup.
Status: RESOLVED → VERIFIED
Whiteboard: [See comment 30 & 31 for remaining issue] fixed-seamonkey1.0 → fixed-seamonkey1.0
Comment on attachment 199798 [details] [diff] [review] patch, v2 (Checked in trunk/branch 1.8 & 1.8.0) Checking in (branch 1.8.0) browser.xml; new revision: 1.40.2.1.2.1; previous revision: 1.40.2.1 done
Attachment #199798 - Attachment description: patch, v2 → patch, v2 (Checked in trunk/branch 1.8 & 1.8.0)
Whiteboard: fixed-seamonkey1.0
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: