57896 - window focusing triggers uncaught exception

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Martin Jacobs]

From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (Win95; U)
BuildID:    2000102320

In this page, javascript-opened windows, when blured then re-focused, will cause 
the message : 
Error:  uncaught exception: [Exception... "Component does not have requested 
interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: 
"<unknown>"]
Source File: 
Line:  0      Column:  0  

Reproducible: Always
Steps to Reproduce:
Click any camera button to get a picture. 
Don't close this new window and click another camera.  
After downloading, next picture will display in front of the first one.  
Here you get the above error message, as for all next pictures.  

One can get this message easily (in Win9x) this way too : 
1/ click a picture
2/ when it shows, blur it by clicking on the main window
3/ on the taskbar, click picture to focus it... 
and get this fascinating message too. 

Actual Results:  Got the above uncaught exception message.  
Nevertheless, program works fine.  
Still worrying though :-( 

Expected Results:  No message, thank you :-)  

As can be seen when executing javascript step by step, this bug is directly 
related to focus() method applied on last window opened.  
Occurs only once for each window, even if blured/focused again.  
Please see #56539 discussion.

Comment 1

[Phil Schwartau]

cc'ing jband to help find the proper component for this bug -

Comment 2

[John Bandhauer]

I tracked this with a breakpoint in NS_NewDOMException. The exception object is 
generated from HTMLInputElementFocus. That function's call to 
nativeThis->Focus() is returning this result code. I think this means that in 
nsHTMLInputElement::SetFocus the call to nsGenericHTMLElement::GetPrimaryFrame 
failed. Inside that method is a QI call:

res = frame->QueryInterface(NS_GET_IID(nsIFormControlFrame),                            
(void**)&aFormControlFrame);

http://lxr.mozilla.org/seamonkey/source/layout/html/content/src/nsGenericHTMLEle
ment.cpp#2357

I don't know why this would fail, but it looks like the guy. I assume that the 
frame was not of the type expected. Is this really an exceptional case? Should 
it really throw a DOM exception into JS?

Comment 3

[Johnny Stenback (:jst)]

Jband, thanks for tracking this down, I did some more poking around here and
it's actually not the QI that fails, the problem is that GetPrimaryFrame()
reutrns NS_NOINTERFACE if the frame isn't found (obviously :-) and in this case
we don't find a frame for the content so we never get to the QI call and we
return the NS_NOINTERFACE code.

As a quick and safe fix for this problem we could do something like this:

Index: layout/html/content/src/nsHTMLInputElement.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/content/src/nsHTMLInputElement.cpp,v
retrieving revision 1.143.2.2
diff -u -r1.143.2.2 nsHTMLInputElement.cpp
--- nsHTMLInputElement.cpp      2000/10/24 02:30:45     1.143.2.2
+++ nsHTMLInputElement.cpp      2000/10/25 20:22:20
@@ -631,7 +631,7 @@
     // select text when we receive focus - only for text and password!
   }

-  return rv;
+  return NS_OK;
 }

 NS_IMETHODIMP

Simply return NS_OK even if GetPrimaryFrame() fails...

However, the right fix would probably be to fix GetPrimaryFrame() to return
NS_OK (or void for all I care) even if there's no frame, but that requires
looking at all the callers to make sure they'll work with that change...

For mozilla0.9 we should at least land the simple fix.

Comment 4

[Martin Jacobs]

About camera icons behavior in this page, see #57860

Comment 5

[Stephen Morris]

For another example of this see:
http://bugscape.netscape.com/show_bug.cgi?id=3338
This bugscape report has an attachment with text popups that throw
the same exception on .focus().
They are saying,"[This bugscape bug] Sounds like a dupe of [this bugzilla bug]".

Comment 6

[HJ]

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

Comment 7

[Martin Jacobs]

Camera icons now working.
Replaced animated gif by DHTML.
10/27/2000 comment canceled.  

Comment 8

[Johnny Stenback (:jst)]

Not sure what really fixed this or when it was fixed but I can't reproduce this
any more either. Marking FIXED.

Comment 9

[Martin Jacobs]

This bug report is about "uncaught exception" when window focused.
Bug still alive as far as I know.
(Cached animated gifs were another story : see #57860 and #20110).  

Comment 10

[Johnny Stenback (:jst)]

Ok, reopening, I must have some changes in my tree that happens to fix this
since I don't see the exceptions any more, I'll look into it.

Comment 11

[Johnny Stenback (:jst)]

Ok, so this is fixed now, I can't reproduce this exception now when switching
focus. Marking FIXED.

Comment 12

[Phil Schwartau]

Using Mozilla debug builds 2001-01-18  8 PM Pacific Time on WinNT, Linux.
Using Mozilla nightly binary 2001011608 on Linux. 


Verifying the NS_NOINTERFACE exception is gone when I switch focus, 
therfore I will mark this bug VERIFIED. However on Linux, I get the 
exception NS_DOM_PROP_ACCESS_DENIED whenever I click on a camera icon 
at the given site. As a result, no gif is displayed in the child window,
just a child-sized rendering of http://www.mozilla.org.


This does not happen on WinNT, only on Linux for both the builds mentioned 
above. Is anyone else seeing this? Should I file a new bug for this,
or is it a dupe of a known bug? 

Comment 13

[Johnny Stenback (:jst)]

Phil, I filed bug 65930 on the ACCESS_DENIED problem on linux.

Comment 14

[Martin Jacobs]

From my humble Win95 platform, with M0.7, OK too.  
Thank you all :-)