7.01 KB, patch
|Details | Diff | Splinter Review|
1.36 KB, application/vnd.mozilla.xul+xml
4.25 KB, patch
|Details | Diff | Splinter Review|
3.67 KB, application/vnd.mozilla.xul+xml
Ability to disable a complete tree instead of looping through each cell and element in it.
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
Target Milestone: --- → mozilla0.9.6
Assignee: hyatt → hewitt
Status: ASSIGNED → NEW
Summary: Ability to Disable trees completely → Ability to disable lists/trees/outliners completely
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.
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 firstname.lastname@example.org. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Adding nsbeta1 and unsetting milestone to have this reevaluated. This is tagged for xul1.0 (ergo mozilla 1.0) [xul1.0-widgets-lists]
Target Milestone: mozilla1.2 → ---
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2
Created attachment 107461 [details] [diff] [review] New <listbox> patch
Attachment #68107 - Attachment is obsolete: true
Comment on attachment 107461 [details] [diff] [review] New <listbox> patch looks good r=varga
Attachment #107461 - Flags: review?(varga) → review+
>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
What's the status of this? Hewitt is gone. I guess he won't sr this anymore.
*** Bug 245446 has been marked as a duplicate of this bug. ***
Attachment #107461 - Flags: superreview?(hewitt) → superreview?(bryner)
Attachment #107461 - Flags: superreview?(bryner) → superreview+
*** Bug 270284 has been marked as a duplicate of this bug. ***
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
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.
Created attachment 172510 [details] Pinstripe's listbox.css
(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...
Created attachment 172625 [details] [diff] [review] Toolkit verison of patch v0.3a (Checked in)
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.
Comment on attachment 172625 [details] [diff] [review] Toolkit verison of patch v0.3a (Checked in) r=mkaply
Attachment #172625 - Flags: review?(mkaply) → review+
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)
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?
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
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.
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: review? → review?(mconnor)
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.
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.
Created attachment 216507 [details] scrollable tree testcase timeless asked for a scrollable tree testcase. Here it is. I think the behavior is still correct.
Attachment #216506 - Flags: review?(mconnor) → review+
patch checked in by timeless. Thanks, everyone.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
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.