Ability to disable lists, trees completely

RESOLVED FIXED in mozilla1.8beta1

Status

()

Core
XUL
P3
enhancement
RESOLVED FIXED
17 years ago
10 years ago

People

(Reporter: varada, Assigned: WeirdAl)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.8beta1
All
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xul1.0-widgets-lists])

Attachments

(4 attachments, 5 obsolete attachments)

(Reporter)

Description

17 years ago
Ability to disable a complete tree instead of looping through each cell and
element in it.

Comment 1

17 years ago
Yes.  

The XUL schema and spec indicate that any select control should be able to be
disabled completely, so this is a XUL1.0 issue.

Marking for XUL1.0.
Status: NEW → ASSIGNED
Summary: Ability to Disable trees compeltely → Ability to Disable trees completely
Whiteboard: [xul1.0-widgets-lists]
Target Milestone: --- → mozilla0.9.6

Comment 2

17 years ago
--> hewitt
Assignee: hyatt → hewitt
Status: ASSIGNED → NEW
Summary: Ability to Disable trees completely → Ability to disable lists/trees/outliners completely

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3

Updated

17 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

17 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

16 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 3

16 years ago
Created attachment 68107 [details] [diff] [review]
Patch for <listbox>

Comment 4

16 years ago
We will also need skin css to make the text in the listitems look disabled. 
Also, listheaders need to look disabled and not respond to the mouse.  Also,
listboxes should become unfocusable when disabled and lose focus if they already
had it.

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 5

16 years ago
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2

Comment 6

16 years ago
Adding nsbeta1 and unsetting milestone to have this reevaluated. This is 
tagged for xul1.0 (ergo mozilla 1.0) [xul1.0-widgets-lists]
Keywords: nsbeta1
Target Milestone: mozilla1.2 → ---

Comment 7

16 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2

Comment 8

16 years ago
Created attachment 107461 [details] [diff] [review]
New <listbox> patch
Attachment #68107 - Attachment is obsolete: true

Updated

16 years ago
Attachment #107461 - Flags: superreview?(hewitt)
Attachment #107461 - Flags: review?(varga)

Comment 9

16 years ago
Comment on attachment 107461 [details] [diff] [review]
New <listbox> patch

looks good
r=varga
Attachment #107461 - Flags: review?(varga) → review+

Comment 10

16 years ago
>We will also need skin css to make the text in the listitems look disabled. 
>Also, listheaders need to look disabled and not respond to the mouse.
This is done in Neil's patch

>Also, listboxes should become unfocusable when disabled and lose focus if they
>already had it.

this also works with this patch as expected, but I don't see where it is done 
is it done automatically for any XUL element ?

keyboard events are disabled too, but again I don't see where they are disabled

This is probably a known behaviour that I'm not aware of, sigh

Comment 11

15 years ago
What's the status of this?
Hewitt is gone. I guess he won't sr this anymore.

Comment 12

14 years ago
*** Bug 245446 has been marked as a duplicate of this bug. ***
Attachment #107461 - Flags: superreview?(hewitt) → superreview?(bryner)
Attachment #107461 - Flags: superreview?(bryner) → superreview+

Updated

14 years ago
Target Milestone: mozilla1.2alpha → mozilla1.8beta

Comment 13

13 years ago
*** Bug 270284 has been marked as a duplicate of this bug. ***

Comment 14

13 years ago
Comment on attachment 107461 [details] [diff] [review]
New <listbox> patch

I didn't check in the parts corresponding to the disabled listheaders because
I'm not happy with that part of the patch. But I did remember to patch the Mac
theme.
Attachment #107461 - Attachment is obsolete: true

Comment 15

13 years ago
Created attachment 172509 [details] [diff] [review]
Toolkit version of patch v0.3

Diff isn't quite right, but that is because pinstripe's listbox.css is
currently a binary file so I'll attach that as a separate file.
Attachment #172509 - Flags: review?(mconnor)

Comment 16

13 years ago
Created attachment 172510 [details]
Pinstripe's listbox.css
Attachment #172510 - Flags: review?(mconnor)

Comment 17

13 years ago
(In reply to comment #15)
>pinstripe's listbox.css is currently a binary file
Well, it was just checked in with the wrong line endings...

Updated

13 years ago
Attachment #172509 - Flags: review?(mconnor)

Updated

13 years ago
Attachment #172510 - Flags: review?(mconnor)

Comment 18

13 years ago
Created attachment 172625 [details] [diff] [review]
Toolkit verison of patch v0.3a (Checked in)
Attachment #172509 - Attachment is obsolete: true
Attachment #172510 - Attachment is obsolete: true
Attachment #172625 - Flags: review?(mconnor)
Comment on attachment 172625 [details] [diff] [review]
Toolkit verison of patch v0.3a (Checked in)

Ian, I'm not likely to get to this in a timely fashion.  There's a number of
toolkit reviewers listed in owners.html that can be asked.

Updated

13 years ago
Attachment #172625 - Flags: review?(mconnor) → review?(mkaply)

Comment 20

13 years ago
Comment on attachment 172625 [details] [diff] [review]
Toolkit verison of patch v0.3a (Checked in)

r=mkaply
Attachment #172625 - Flags: review?(mkaply) → review+

Comment 21

13 years ago
Comment on attachment 172625 [details] [diff] [review]
Toolkit verison of patch v0.3a (Checked in)

Checking in content/widgets/listbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/listbox.xml,v	<--  listbox.xml
new revision: 1.10; previous revision: 1.9
done
Checking in themes/qute/global/listbox.css;
/cvsroot/mozilla/toolkit/themes/qute/global/listbox.css,v  <--	listbox.css
new revision: 1.4; previous revision: 1.3
done
Checking in themes/winstripe/global/listbox.css;
/cvsroot/mozilla/toolkit/themes/winstripe/global/listbox.css,v	<-- 
listbox.css

new revision: 1.6; previous revision: 1.5
done
Attachment #172625 - Attachment description: Toolkit verison of patch v0.3a → Toolkit verison of patch v0.3a (Checked in)

Comment 22

13 years ago
We need to test to make sure the disabled widgets are also marked disabled in
the accessibility interfaces. Any testcases or examples of this in the current
builds' UI?
(Assignee)

Comment 23

12 years ago
Okay, so outliners have now been adopted into the more generic <xul:tree/> widget.  hewitt's no longer with us, so I'm reassigning to default owner/QA.

I'll take a stab at creating a patch for trees.
Assignee: hewitt → Jan.Varga
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.trees
Summary: Ability to disable lists/trees/outliners completely → Ability to disable lists, trees completely
(Assignee)

Comment 24

12 years ago
Hm.  On careful testing in Firefox 1.5 and SeaMonkey trunk, key presses are disabled, but the user can still click around the tree.  Firefox's tree looks like it's disabled, but styling of the treechildren with a background color shows this isn't quite the case.
(Assignee)

Comment 25

12 years ago
Created attachment 216491 [details] [diff] [review]
<xul:tree disabled="true"/>

This is a pretty simple solution:  we simply stop the event and cancel its default before letting it get to any treechildren elements.  Trying to stop it at the treechildren would mean knowing how to reach the tree element, and that would have been a bit longer path than I'd want to take.

This patch doesn't fix the styling of disabled trees for SeaMonkey.  I figure that belongs to a different bug.
Attachment #216491 - Flags: superreview?(neil)
Attachment #216491 - Flags: review?
(Assignee)

Updated

12 years ago
Attachment #216491 - Flags: review? → review?(mconnor)
(Assignee)

Updated

12 years ago
Assignee: Jan.Varga → ajvincent
(Assignee)

Comment 26

12 years ago
Created attachment 216505 [details]
testcase

I'm rethinking whether the patch I submitted is the best solution:
<NeilAway> all disabled xul controls still get events

My patch doesn't do that.
(Assignee)

Comment 27

12 years ago
Created attachment 216506 [details] [diff] [review]
<xul:tree disabled="true"/> better patch

I'd miscalculated; only the topmost treechildren descendant (the child) of the tree element implements tree.xml#treebody.  So it was a matter of referring to this.parentNode instead of this, like the rest of the treebody binding does.
Attachment #216491 - Attachment is obsolete: true
Attachment #216491 - Flags: superreview?(neil)
Attachment #216491 - Flags: review?(mconnor)
Attachment #216506 - Flags: superreview?
Attachment #216506 - Flags: review?(mconnor)
(Assignee)

Comment 28

12 years ago
Created attachment 216507 [details]
scrollable tree testcase

timeless asked for a scrollable tree testcase.  Here it is.  I think the behavior is still correct.

Updated

12 years ago
Attachment #216506 - Flags: superreview? → superreview+

Updated

12 years ago
Attachment #216506 - Flags: review?(mconnor) → review+
(Assignee)

Updated

12 years ago
Blocks: 332775
(Assignee)

Comment 29

12 years ago
patch checked in by timeless.  Thanks, everyone.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

11 years ago
Duplicate of this bug: 366762

Updated

10 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.