The default bug view has changed. See this FAQ.

Custom tree views don't work anymore in a remote XUL file since FF 1.5.0.4

RESOLVED WONTFIX

Status

()

Core
XUL
--
major
RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: Laurent Jouanneau, Assigned: janv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Because of a security issue ( bug #326501 ), the fix of this issue was to disallow the use of custom tree views in a remote XUL.

This fix is a big issue because it breaks many web application. Custom tree views are very useful. A solution should be found to allow this feature.

Reproducible: Always

Steps to Reproduce:
1. open the given URL in Firefox 1.5.0.4

Actual Results:  
A security error appears in the javascript console, when setting the custom view to the tree.

Expected Results:  
The tree should be filled by the custom view.
(Reporter)

Updated

11 years ago
Blocks: 133695

Comment 1

11 years ago
Same happens on our systems.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060508  Firefox/1.5.0.4

Comment 2

11 years ago
*** Bug 340546 has been marked as a duplicate of this bug. ***

Comment 3

11 years ago
Created attachment 224605 [details]
Here is a sample remote XUL that shows the problem

The sample code is from http://www.xulplanet.com/tutorials/xultu/treeview.html

Comment 4

11 years ago
(In reply to comment #0)

I just want to add a comment about why custom tree view is important for remote XUL applications.

We currently have a commercial web server manager written in XUL, and it uses custom tree view to display the files in a directory.

After FF 1.5.4 broke custom tree view, we have been forced to re-write the code to use content tree view instead.

Content tee view works, but is 5 to 10 times slower than the version using custom view.  The most likely reason is that with the content view, the entire DOM has to be build all at once when the directory is refreshed.  With custom tree view, only the rows that are visible needs to be computed via getCellText().  On a directory with several thousand files the building of the content view tree can take a long time, causing users to see "A Script on this page is busy...", which is very user unfriendly and we are still trying to get around that problem using some setTimeout hacks.

Comment 5

10 years ago
CONFIRMing; Serious
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

10 years ago
Sorry to spam the bug but does anyone have _any_ workaround for this, no matter how ugly? This totally breaks my XUL application, since the interest for this bug seems so low I can only conclude that remote XUL isn't used much at the moment.

Comment 7

10 years ago
You can revert this patch changes (https://bugzilla.mozilla.org/show_bug.cgi?id=326501#attach_216077) from trunk and
build your own version of product. I think it is only workaround which will help. 

Comment 8

9 years ago
Well it took me some time to find out that it is possible to enable custom trees in remote xul by gaining UniversalBrowserWrite. Writing this just in case someone like me looks at this.

Updated

9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
(Reporter)

Comment 9

3 years ago
As remote XUL has been disabled since few years into Firefox, we can close this bug.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.