XP Menus need to dynamically reconstruct anonymous content on attribute changes

RESOLVED FIXED in M10

Status

()

Core
XUL
P3
normal
RESOLVED FIXED
19 years ago
a year ago

People

(Reporter: David Hyatt, Assigned: shaver)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Whenever the value, acceltext, et. al. attributes change, an XP menu that
contains anonymous content built from those attributes needs to dynamically
destroy and recreate that anonymous content with the new values.
(Reporter)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M10

Updated

19 years ago
Blocks: 12670

Updated

19 years ago
Assignee: hyatt → shaver
Status: ASSIGNED → NEW

Comment 1

19 years ago
reassigning to shaver
Status: NEW → ASSIGNED
I've got this working in my tree, and I'm about ready to check in.

Do we have a test case?
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I just checked in a change that stops using <div>Menu <u>T</u>ext</div> for
accesskey, and instead lets titledbutton draw the accesskey underline itself.
To heck with a test case. =)

myMenuItem.setAttribute("accesskey", "a") works now, etc.

Updated

19 years ago
QA Contact: ckritzer → hyatt

Comment 4

19 years ago
Assigning to originator per new organizational structure.

Updated

19 years ago
QA Contact: hyatt → ckritzer

Comment 5

19 years ago
Changing QA Contact back to ckritzer@netscape.com

Comment 6

19 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Updated

19 years ago
QA Contact: ckritzer → jrgm

Comment 7

19 years ago
Massive QA Contact update.

Updated

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