Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

tree view issue in FF 1.5.0.4

2 views
Skip to first unread message

Laurent Jouanneau

unread,
May 31, 2006, 7:53:41 AM5/31/06
to
Hello

I just discovered the fix of a security issue with custom tree views in
a remote xul page. ( https://bugzilla.mozilla.org/show_bug.cgi?id=326501
and
http://lxr.mozilla.org/mozilla1.8.0/source/layout/xul/base/src/tree/src/nsTreeBoxObject.cpp#193

).

I don't know exactly what is this security issue, but this fix causes an
other *big* issue : it will break *many* web application !

So, are you working on a *real* solution on this ? a *real* solution
means, a solution which permit us to use a custom tree view in a remote
app.

thanks

Laurent

jefdotpeeraer@telenetdotbe

unread,
Jun 1, 2006, 2:40:37 AM6/1/06
to
Laurent Jouanneau schreef:
see my post a litle bit higher. to me it seems that remote XUL doesn't
deserves teh attention it needs. even at xul planet they don't care !


jef peeraer

Fabio Serra

unread,
Jun 1, 2006, 8:04:51 AM6/1/06
to
jefdotpeeraer@telenetdotbe wrote:
>> Laurent
> see my post a litle bit higher. to me it seems that remote XUL doesn't
> deserves teh attention it needs. even at xul planet they don't care !

Right, this is the sad true. In all these years nothing has been done to improve
remote XUL while Flex, XAML, Ajax widgets toolkit and others are advancing fast.
If you read one of the latest Goodger's post
(http://weblogs.mozillazine.org/ben/archives/015929.html) you'll see that there
isn't any mention about remote xul.

Boris Zbarsky

unread,
Jun 1, 2006, 12:14:27 PM6/1/06
to

Remote XUL is a hard problem to solve given the current arch of a lot of XUL and
XBL. There's not much to say about it until these (esp. XBL) are rearchitected
with an eye to secure remote XUL...

The problem is finding someone to do the work, as usual. There are only so many
people I see willing to spend time on this stuff, and they're all always swamped.

If you want to help, start by coming up with a concrete proposal for how this
stuff should behave in a secure yet usable way.

-Boris

u...@microshare.com.au

unread,
Jun 2, 2006, 6:31:54 AM6/2/06
to
I don't know what all the fuss is about remote XUL. It works for me.

Try http://rio.microshare.net

It's a combination of XUL and AJAX and provides all the remoting I
need.

Uwe.

jefdotpeeraer@telenetdotbe

unread,
Jun 2, 2006, 7:11:13 AM6/2/06
to
u...@microshare.com.au schreef:

> I don't know what all the fuss is about remote XUL. It works for me.
i'll bet you're not using some kind of nsTreeView, because these dont
work in newer ff/moz versions.

jef peeraer

Neil

unread,
Jun 2, 2006, 7:12:23 AM6/2/06
to
u...@microshare.com.au wrote:

>I don't know what all the fuss is about remote XUL. It works for me.
>

Lots of remote XUL does work, but there are parts that are hard to make
work safely.

--
Warning: May contain traces of nuts.

Fabio Serra

unread,
Jun 2, 2006, 11:52:33 AM6/2/06
to
Boris Zbarsky wrote:
> If you want to help, start by coming up with a concrete proposal for how
> this stuff should behave in a secure yet usable way.

There are a lot of small things that can be fixed/improved and long time
ago we started a todo list:
http://wiki.mozilla.org/XUL:Remove_Privilege
I proposed to load external DTD for simplify the localization of remote
xul application and I suggested to add more window dialogs like
confirmEx() confirmCheck(). Other things could be useful is to enable
the sort in the <treee> when the treerows are created using DOM, fix the
<wizard>, enable XHR to call to external domains using the same security
policy used by Flash
(http://www.adobe.com/devnet/flash/articles/fplayer_security.html),
Anyway, I don't want to blame anyone, but I'm afraid because XUL
was (is?) so close to be the best environment to develop rich web
applications and I think the reasons why I started to using xul
(http://faser.net/mab/why_use_xul.cfm) are still valid, but now there
are more competitors. The competitors (Flash/Flex, JWS, XAML, Ajax
Toolkit, Adobe Apollo Platform etc) have understood that public web site
and web applications are not the same thing and for rich web
applications the HTML is not suitable for building the UI. For example,
IE with XAML is doing the same things we have been doing with xul for
more than 4 years.

David

unread,
Jun 2, 2006, 4:22:07 PM6/2/06
to

How do you make a treeview work safely?? if it doesn't work at all.

The point in remote applications is not having to install anything on
the client. How do you implement a native treeview without installing
anything on the client?

How do I show the contents of a table retrieved via XMLHttpRequest and
do all the administration about the data I have, and the one I need,
without using a customTreeView??

Yes, there are things that are difficult to make as remote
applications... ¡everything!.. but now some (the most important one)
are imposible.

I'm very mad about this issue, not because of the issue itself, but for
the fact that XUL is publizised (sorry if it is not the propper
spelling) as a way of making remote applications, and this is becoming
more and more false with every new Firefox version.

If there is no willing to keep compatibility with remote application
programming, then it should be said, and we don't botther any more
trying to make things work, just start using some other developing
environment.

David.

Boris Zbarsky

unread,
Jun 2, 2006, 4:38:38 PM6/2/06
to
David wrote:

> Neil wrote:
>> Lots of remote XUL does work, but there are parts that are hard to make
>> work safely.
>
> How do you make a treeview work safely?? if it doesn't work at all.

When Neil says "safely" he means "safe for the user no matter what the XUL
author is doing". We haven't figured out how to do that for tree views yet;
that's why remote tree views are disabled....

Again, no one is happy that they have been disabled. But it looks like making
them safe will involve pretty much completely rearchitecting the tree widget
(possibly out of existence). We couldn't quite do that for 1.8.0.4 given the
timeframes involved and on a stable branch to boot.

This is an area where help is very much wanted -- there are simply not enough
people with a handle on XUL on the one hand and security issues on the other to
go around. So if you know such people and can convince them to work on
improving XUL, that would rock.

-Boris

Robert O'Callahan

unread,
Jun 6, 2006, 1:17:47 AM6/6/06
to
Boris Zbarsky wrote:
> Again, no one is happy that they have been disabled. But it looks like
> making them safe will involve pretty much completely rearchitecting the
> tree widget (possibly out of existence). We couldn't quite do that for
> 1.8.0.4 given the timeframes involved and on a stable branch to boot.
>
> This is an area where help is very much wanted -- there are simply not
> enough people with a handle on XUL on the one hand and security issues
> on the other to go around. So if you know such people and can convince
> them to work on improving XUL, that would rock.

I'll have a go at fixing this. It might not be as hard as I originally
thought. Or, it might :-).

Rob

Robert O'Callahan

unread,
Jun 14, 2006, 10:27:08 PM6/14/06
to
I've been working on allowing remote nsITreeViews. Currently I'm stumped
because I can't find an example that worked *before* the recent changed
disabled them. Can someone point me at an example on a public Web site
that worked, on trunk, up to a month ago?

Rob

Neil

unread,
Jun 15, 2006, 5:34:22 AM6/15/06
to
Robert O'Callahan wrote:

>I've been working on allowing remote nsITreeViews. Currently I'm stumped because I can't find an example that worked *before* the recent changed disabled them. Can someone point me at an example on a public Web site that worked, on trunk, up to a month ago?
>
>

http://neil.rashbook.org/primary.xul works on 1.8.0, and I just added a
stub for the new trunk nsITreeView::IsSelectable method, so it should work.

Gavin Sharp

unread,
Jun 15, 2006, 2:06:48 PM6/15/06
to
Neil wrote:
> http://neil.rashbook.org/primary.xul works on 1.8.0, and I just added
> a stub for the new trunk nsITreeView::IsSelectable method, so it
> should work.

I think Neil meant http://neil.rashbrook.org/primary.xul :)

Gavin

Neil

unread,
Jun 15, 2006, 8:13:09 PM6/15/06
to
Gavin Sharp wrote:

>Neil wrote:
>
>
>>[typo of my surname deleted to save me further embarassment]


>>
>>
>I think Neil meant http://neil.rashbrook.org/primary.xul :)
>
>

D'oh :-[ Does this new server support cancels?

Sander Steffann

unread,
Jul 18, 2006, 6:04:42 PM7/18/06
to dev-te...@lists.mozilla.org

Robert O wrote:
>
> I'll have a go at fixing this. It might not be as hard as I originally
> thought. Or, it might :-).
>

Any news on this? I just started to use XUL for remote applications, and it
looks very promising. Not being able to use treeviews would make my work a
lot harder, so I would realy appreciate any improvements here!

Thanks,
Sander.

--
View this message in context: http://www.nabble.com/tree-view-issue-in-FF-1.5.0.4-tf1710185.html#a5387316
Sent from the Mozilla - XPFE forum at Nabble.com.

Tei

unread,
Jul 19, 2006, 4:07:16 AM7/19/06
to dev-te...@lists.mozilla.org
On 7/19/06, Sander Steffann <s.ste...@computel.nl> wrote:

>
>
> Robert O wrote:
> >
> > I'll have a go at fixing this. It might not be as hard as I originally
> > thought. Or, it might :-).
> >
>
> Any news on this? I just started to use XUL for remote applications, and it
> looks very promising. Not being able to use treeviews would make my work a
> lot harder, so I would realy appreciate any improvements here!
>

I actually use listview for remote xul apps in production. But I am
rebuilding some apps to use tree because is more advanced (support
colum reordering, and other features), and breaking tree will stop my
work in the tracks. Please, dont drop tree from unprivileged remote
xul. :I

--Tei

0 new messages