[Remote XUL] Rows not selecting in outliner

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
18 years ago
18 years ago

People

(Reporter: tack-bugzilla, Assigned: hyatt)

Tracking

Trunk
mozilla0.9.7
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xul1.0-widgets-outliner], )

Reporter

Description

18 years ago
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

18 years ago
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?
Assignee: trudelle → hyatt
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets
Ever confirmed: true
Assignee

Updated

18 years ago
Blocks: 70753
Status: NEW → ASSIGNED
Whiteboard: [xul1.0-widgets-outliner]
Target Milestone: --- → mozilla0.9.7

Comment 2

18 years ago
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?
Assignee

Updated

18 years ago
Summary: Rows not selecting in outliner → [Remote XUL] Rows not selecting in outliner
Assignee

Comment 3

18 years ago
jband, any ideas?

Comment 4

18 years ago
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.
Assignee

Comment 5

18 years ago
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.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.