91041 - [Remote XUL] Rows not selecting in outliner

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Jason Tackaberry]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010716
BuildID:    2001071608

Outliners fetched outside of the chrome directory (http in this example) will
not allow rows to be selected.  No errors on the console or in javascript. 
outlinerbody does not appear to respond to onselect events either (as
onselect='alert("foo")' does not alert as it should on selecting a row).

Reproducible: Always
Steps to Reproduce:
1. load the page
2. try to click on a row
3. marvel as nothing happens

Comment 1

[John Morrison]

Hmm, well I get a slew of errors (after a short period of waiting):

Error: [Exception... "'JavaScript component does not have a method named: 
 "isContainer"' when calling method: [nsIOutlinerView::isContainer]"  
 nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  
 location: "<unknown>"  data: no]


And, indeed, that example implements a subset of the methods on that 
interface, and does not implement |isContainer|. However, when that 
same XUL is placed inside a chrome .jar file, it works correctly (or 
at least without errors). 

I'm completely out to lunch on what the rules are for "inheriting" in 
some way (see, you can tell by my hand-waving that I _really_ don't know).

But it may be the case that a xul file outside of the chrome is obligated
to implement the entire interface. Dave? Jan? Brian?

Comment 2

[Christian Reis]

Hyatt, what's your take on this? Its still happening on 2001082308 linux here.

It does work inside the chrome:// directory fine, so it could be a security problem?

Comment 3

[David Hyatt]

jband, any ideas?

Comment 4

[John Bandhauer]

I dunno.

XPConenct never tries to verify that a given object has a given method of an 
interface unless someone tries to actually call the method.

I have no idea why this would work any differently in chrome.

I'm not clear fom what you say if it actually does work in the chrome - or just 
that no errors are spewed? I did not try sticking this in a chrome jar myself. 
I'm thinking some other code might eat the chrome errors before you see them?

I tried this by saving this locally and running as a file: url. I see the errors 
on every repaint. 

Here is a snippet of the stack that is calling isContainer...

...
nsOutlinerBodyFrame::PrefillPropertyArray(int 0x00000000, nsOutlinerColumn * 
0x00000000) line 1245
nsOutlinerBodyFrame::PaintRow(nsOutlinerBodyFrame * const 0x02b3315c, int 
0x00000000, const nsRect & {...}, nsIPresContext * 0x04439960, 
nsIRenderingContext & {...}, const nsRect & {...}, nsFramePaintLayer 
eFramePaintLayer_Underlay) line 1605
nsOutlinerBodyFrame::Paint(nsOutlinerBodyFrame * const 0x02b3315c, 
nsIPresContext * 0x04439960, nsIRenderingContext & {...}, const nsRect & {...}, 
nsFramePaintLayer eFramePaintLayer_Underlay) line 1547
PresShell::Paint(PresShell * const 0x0443ac94, nsIView * 0x041a3ee0, 
nsIRenderingContext & {...}, const nsRect & {...}) line 5377 + 34 bytes
nsView::Paint(nsView * const 0x041a3ee0, nsIRenderingContext & {...}, const 
nsRect & {...}, unsigned int 0x00000080, int & 0x1002afc5) line 275
nsViewManager::RenderDisplayListElement(DisplayListElement2 * 0x04441550, 
nsIRenderingContext & {...}) line 1439
nsViewManager::RenderViews(nsIView * 0x041a3ee0, nsIRenderingContext & {...}, 
const nsRect & {...}, int & 0x00000000) line 1364
nsViewManager::Refresh(nsIView * 0x041a3ee0, nsIRenderingContext * 0x04441780, 
const nsRect * 0x0012f5fc, unsigned int 0x00000001) line 901
nsViewManager::DispatchEvent(nsViewManager * const 0x04438bd0, nsGUIEvent * 
0x0012f73c, nsEventStatus * 0x0012f640) line 1958
HandleEvent(nsGUIEvent * 0x0012f73c) line 68
nsWindow::DispatchEvent(nsWindow * const 0x041a3da4, nsGUIEvent * 0x0012f73c, 
nsEventStatus & nsEventStatus_eIgnore) line 728 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f73c, nsEventStatus & 
nsEventStatus_eIgnore) line 754
nsWindow::OnPaint() line 4070 + 28 bytes
...

Anyone who wants to debug can stop at the place where that xpconenct error is 
generated by setting a breakpoint in:

xpcwrappedjsclass.cpp

http://lxr.mozilla.org/seamonkey/search?string=HAS_NO_FUNCTION_NAMED

I suggest hacking the sample to add 2 or 3 orders of magnitude *less* rows... 
10000 is excessive for debugging!

I think it is clear that if isContainer is needed in this interface, then its 
absence explains the errors. If the behavior really is materially different in 
the chrome case, then I'm not the guy to explain why.

Comment 5

[David Hyatt]

Yeah, I'm gonna mark this invalid.  My take on this is that you should be
implementing the full nsIOutlinerView interface, since literally every method in
that interface is used by the front-end outliner code.