Last Comment Bug 104360 - In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no properties"; (When closing tabs with Site Navigation Bar showed)
: In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has ...
Status: VERIFIED FIXED
: fixed-seamonkey1.0, fixed1.8
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: x86 All
: -- normal with 4 votes (vote)
: seamonkey1.0beta
Assigned To: Alex Vincent [:WeirdAl]
: Patty Mac
Mentors:
: 107113 142401 192386 212020 216580 240389 251572 (view as bug list)
Depends on: 104361
Blocks: 103053 320693
  Show dependency treegraph
 
Reported: 2001-10-12 05:19 PDT by Henrik Gemal
Modified: 2009-06-14 19:05 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (1.28 KB, patch)
2005-10-16 13:05 PDT, Alex Vincent [:WeirdAl]
no flags Details | Diff | Splinter Review
patch, v2 (Checked in trunk/branch 1.8 & 1.8.0) (944 bytes, patch)
2005-10-17 07:17 PDT, Alex Vincent [:WeirdAl]
neil: review+
neil: superreview+
iann_bugzilla: approval‑seamonkey1.0+
Details | Diff | Splinter Review

Description Henrik Gemal 2001-10-12 05:19:42 PDT
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
Comment 1 Henrik Gemal 2001-10-12 05:49:05 PDT
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

Comment 2 Henrik Gemal 2001-10-27 06:00:33 PDT
*** Bug 107113 has been marked as a duplicate of this bug. ***
Comment 3 Peter Trudelle 2001-11-27 16:25:23 PST
->tabbed browser
Comment 4 Henrik Gemal 2002-01-18 02:03:29 PST
still valid in 20020116

when closing a tab where you got the "host could not be found" alert
Comment 5 David Hyatt 2002-01-21 13:52:48 PST
Reassigning to new component owner.
Comment 6 jag (Peter Annema) 2002-01-21 22:28:45 PST
This has the same underlying problem as bug 104361.
Comment 7 Serge Gautherie (:sgautherie) 2002-11-28 14:55:44 PST
"Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2) Gecko/20021126"

Bug still there: as described in report.
Comment 8 Christian :Biesinger (don't email me, ping me on IRC) 2002-11-28 15:14:38 PST
*** Bug 142401 has been marked as a duplicate of this bug. ***
Comment 9 Andreas Kunz 2003-01-05 16:41:13 PST
Henrik, can you test this again?
It works for me with 2003010505 on Win2k.
Comment 10 Andreas Kunz 2003-01-05 16:46:47 PST
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...
Comment 11 Serge Gautherie (:sgautherie) 2003-01-07 02:41:32 PST
[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.
Comment 12 Serge Gautherie (:sgautherie) 2003-03-16 09:46:24 PST
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312]

Bug still there.
Comment 13 Serge Gautherie (:sgautherie) 2003-04-02 07:28:01 PST
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

Bug still there. (with v1.3 profile, at least)
Comment 14 Serge Gautherie (:sgautherie) 2003-04-06 09:57:55 PDT
I suggest to change the summary to:

In <chrome://global/content/bindings/browser.xml>, "Error: this.docShell has no
properties"
Comment 15 Serge Gautherie (:sgautherie) 2003-04-14 02:51:16 PDT
*Target Milestone "mozilla1.1alpha" is way overdue...
Comment 16 Serge Gautherie (:sgautherie) 2003-05-09 06:16:21 PDT
[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)
Comment 17 Vedran Miletic 2003-10-05 08:04:12 PDT
retargeting
Comment 18 louis bennett 2003-10-21 17:11:32 PDT
*** Bug 212020 has been marked as a duplicate of this bug. ***
Comment 19 Oliver Klee 2003-11-02 14:04:17 PST
Is bug 216580 a dupe of this one?
Comment 20 Serge Gautherie (:sgautherie) 2003-11-02 14:29:03 PST
*** Bug 216580 has been marked as a duplicate of this bug. ***
Comment 21 Serge Gautherie (:sgautherie) 2003-11-02 14:51:12 PST
Changing 'OS' from 'Windows 2000' to 'All', since bug 216580 report is about Linux.
Comment 22 Asa Dotzler [:asa] 2004-04-06 16:17:20 PDT
*** Bug 192386 has been marked as a duplicate of this bug. ***
Comment 23 Stefan Borggraefe 2004-04-13 07:36:50 PDT
*** Bug 240389 has been marked as a duplicate of this bug. ***
Comment 24 Gérard Talbot 2004-09-24 13:10:27 PDT
*** Bug 251572 has been marked as a duplicate of this bug. ***
Comment 25 Gérard Talbot 2004-09-24 13:12:01 PDT
I have seen this error reported in the js console hundreds and hundreds of
times. I wish someone would *kill* that error for good.
Comment 26 Henrik Skupin (:whimboo) 2004-12-07 00:43:40 PST
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.
Comment 27 Gérard Talbot 2004-12-07 07:25:14 PST
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

Comment 28 Henrik Skupin (:whimboo) 2004-12-08 11:56:28 PST
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.
Comment 29 Mel Reyes 2004-12-09 09:21:04 PST
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.
Comment 30 Serge Gautherie (:sgautherie) 2004-12-11 11:40:28 PST
[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) ?
Comment 31 Gérard Talbot 2004-12-11 13:35:51 PST
> 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.
Comment 32 Henrik Gemal 2005-04-19 04:45:06 PDT
Error: this.docShell has no properties
Source File: chrome://global/content/bindings/browser.xml
Line: 0

still in Mozilla Firefox 20050418
Comment 33 Whoops 2005-04-21 01:45:49 PDT
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
Comment 34 Yuh-Ruey Chen 2005-04-28 10:35:25 PDT
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).
Comment 35 sasha 2005-05-17 09:00:34 PDT
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.
Comment 36 Serge Gautherie (:sgautherie) 2005-05-17 09:42:02 PDT
(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 ?
Comment 37 sasha 2005-05-17 10:07:02 PDT
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.





Comment 38 Serge Gautherie (:sgautherie) 2005-05-17 10:15:58 PDT
(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...
Comment 39 Henrik Skupin (:whimboo) 2005-06-05 06:11:47 PDT
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.
Comment 40 Henrik Skupin (:whimboo) 2005-06-05 14:26:27 PDT
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
Comment 41 Alex Vincent [:WeirdAl] 2005-10-16 13:04:41 PDT
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.
Comment 42 Alex Vincent [:WeirdAl] 2005-10-16 13:05:45 PDT
Created attachment 199761 [details] [diff] [review]
patch
Comment 43 Boris Zbarsky [:bz] 2005-10-16 18:58:12 PDT
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....
Comment 44 Alex Vincent [:WeirdAl] 2005-10-16 19:00:48 PDT
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.)
Comment 45 neil@parkwaycc.co.uk 2005-10-17 02:08:20 PDT
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?
Comment 46 Boris Zbarsky [:bz] 2005-10-17 05:43:15 PDT
Er... yes... Did that not happen as part of bug 303839?
Comment 47 Alex Vincent [:WeirdAl] 2005-10-17 07:12:53 PDT
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.
Comment 48 Alex Vincent [:WeirdAl] 2005-10-17 07:17:35 PDT
Created attachment 199798 [details] [diff] [review]
patch, v2 (Checked in trunk/branch 1.8 & 1.8.0)

This patch copies over the change to toolkit/.../browser.xml into
xpfe/.../browser.xml.
Comment 49 Doron Rosenberg (IBM) 2005-10-19 09:46:24 PDT
checked into trunk
Comment 50 Henrik Gemal 2005-10-19 11:40:28 PDT
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?
Comment 51 Alex Vincent [:WeirdAl] 2005-10-19 11:48:09 PDT
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.
Comment 52 Henrik Gemal 2005-10-19 13:00:14 PDT
I've created Bug 313048 since I still see this issue in nightly builds of firefox
Comment 53 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-12-14 08:24:28 PST
Moving to correct product so we can grant a=
Comment 54 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-12-14 08:26:45 PST
Comment on attachment 199798 [details] [diff] [review]
patch, v2 (Checked in trunk/branch 1.8 & 1.8.0)

First a=me
Comment 55 Ian Neal 2005-12-14 09:08:42 PST
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!
Comment 56 Mark Banner (:standard8) 2005-12-14 09:53:10 PST
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
Comment 57 Serge Gautherie (:sgautherie) 2005-12-17 18:10:09 PST
(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.
Comment 58 Ian Neal 2005-12-22 16:25:26 PST
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

Note You need to log in before you can comment on or make changes to this bug.