The default bug view has changed. See this FAQ.

still content can implement tree views

RESOLVED FIXED

Status

()

Core
XUL
--
critical
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: shutdown, Assigned: roc)

Tracking

({verified1.8.0.7, verified1.8.1})

Trunk
verified1.8.0.7, verified1.8.1
Points:
---
Bug Flags:
blocking1.8.1 +
blocking1.8.0.7 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
See bug 326501. nsINativeTreeView check, introduced by said bug, can be circumvented by using treeElement.boxObject.setPropertyAsSupports().
(Reporter)

Comment 1

11 years ago
Created attachment 228655 [details]
testcase

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b1) Gecko/20060709 BonEcho/2.0b1
TB20774884Z
Assignee: Jan.Varga → roc
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?
Whiteboard: [sg:critical?]
Created attachment 229212 [details] [diff] [review]
fix

Fairly simple.
Attachment #229212 - Flags: superreview?(bzbarsky)
Attachment #229212 - Flags: review?(bzbarsky)

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+
Comment on attachment 229212 [details] [diff] [review]
fix

This works, but really we should just be storing this as a member, not a property, imo...  The property mechanism is there to allow storage of random things, so taking up parts of the namespace is not so cool.
Attachment #229212 - Flags: superreview?(bzbarsky)
Attachment #229212 - Flags: superreview+
Attachment #229212 - Flags: review?(bzbarsky)
Attachment #229212 - Flags: review+
Yeah. Unfortunately fixing the usage of the "view" property requires either adding a new private interface to nsTreeBoxObject or doing deeper changes than would be good for branch. So I'll go with this patch for trunk and branch, for now.
checked in on trunk
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Comment on attachment 229212 [details] [diff] [review]
fix

need this on branches
Attachment #229212 - Flags: approval1.8.1?
Attachment #229212 - Flags: approval1.8.0.6?
Comment on attachment 229212 [details] [diff] [review]
fix

guess I'll wait for approval requests until this has been on trunk for a couple of days
Attachment #229212 - Flags: approval1.8.1?
Attachment #229212 - Flags: approval1.8.0.6?

Comment 8

11 years ago
Created attachment 230292 [details] [diff] [review]
Fix as per comment #3

Untested as yet, though; might leak or worse...
So when nsTreeBodyFrame creates the view in EnsureView(), how does nsTreeBoxObject find out about it so nsTreeBoxObject::GetView() works?

Comment 10

11 years ago
Comment on attachment 230292 [details] [diff] [review]
Fix as per comment #3

>         // Hook up the view.
>         if (view)
>-          SetView(view);
>+          mTreeBoxObject->SetView(view);
The solution eluded me for a while, until I came up with this flash of inspiration; assuming that you don't have malformed xul, when you don't actually have a box object, so I'll need to null-check.

Comment 11

11 years ago
Created attachment 230643 [details] [diff] [review]
Real fix as per comment #3

I had to move some of the view creation logic into the box object because people expect to be able to get a view from an invisible (collapsed) tree.
Attachment #230292 - Attachment is obsolete: true
Attachment #230643 - Flags: superreview?(bzbarsky)
Attachment #230643 - Flags: review?(roc)
Flags: blocking1.8.0.6? → blocking1.8.0.6+
Neil, can you just get roc to r+sr this?  I'm not going to be able to get to it in the near future (several weeks).
Comment on attachment 229212 [details] [diff] [review]
fix

branch security fixes
Attachment #229212 - Flags: approval1.8.1?
Attachment #229212 - Flags: approval1.8.0.6?
Comment on attachment 230643 [details] [diff] [review]
Real fix as per comment #3

Looks good, thanks. I think we should take this on trunk only, though, since it's somewhat invasive.
Attachment #230643 - Flags: superreview?(bzbarsky)
Attachment #230643 - Flags: superreview+
Attachment #230643 - Flags: review?(roc)
Attachment #230643 - Flags: review+
Comment on attachment 229212 [details] [diff] [review]
fix

a=dbaron on behalf of drivers.  Please check in to MOZILLA_1_8_BRANCH and mark fixed1.8.1 once you have done so.
Attachment #229212 - Flags: approval1.8.1? → approval1.8.1+
Checked into 1.8.1 branch.
Keywords: fixed1.8.1
Comment on attachment 229212 [details] [diff] [review]
fix

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #229212 - Flags: approval1.8.0.7? → approval1.8.0.7+
Fixed on 1.8.0 branch
Keywords: fixed1.8.0.7

Comment 19

11 years ago
v.fixed on both branches with 8/24 nightly builds, no crash with testcase:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7pre) Gecko/20060824 Firefox/1.5.0.7pre
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1b2) Gecko/20060824 BonEcho/2.0b2
Keywords: fixed1.8.0.7, fixed1.8.1 → verified1.8.0.7, verified1.8.1
Group: security

Updated

9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.