Closed Bug 9635 Opened 25 years ago Closed 25 years ago

sched: Default buttons in dialogs

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: trudelle, Assigned: hangas)

References

Details

Default buttons in dialogs 1 day sdagley 0%
Mass changing all XPToolkit M9 feature 'bugs' to target as p2 for M9
Mass changing all M9 feature 'bugs' to 'enhancement severity.
Blocks: 9639
Status: NEW → ASSIGNED
Blocks: 9542
Target Milestone: M9 → M10
No longer blocks: 9542
No longer blocks: 9639
Blocks: 9673
Whiteboard: 2 days (currently studying nsXULKeyListener per hyatt's recommendation)
Whiteboard: 2 days (currently studying nsXULKeyListener per hyatt's recommendation) → working on it
Whiteboard: working on it → 1 day to complete, week of 9/20-9/25
Why is this 1 day M10 task getting delayed to the very end of M11?
it's an xp change which I don't want to try and land while I'm not in the office
Assignee: sdagley → hangas
Status: ASSIGNED → NEW
After getting concerns over adding yet another event listener mechanism to handle dialog default keys davidm, hangas, saari and I reviewed this feature and decided that the best mechanism to handle it would be changing dialogOverlay.xul to use the standard key listener code. This has the added benefit of making dialog writers use dialogOverlay.xul so that they get dialogs that look consistent and behave in the proper manner for each platform. Reassigning to hangas who owns dialogOverlay.xul for the coup de grâce.
Status: NEW → ASSIGNED
Target Milestone: M10 → M11
Depends on: 14424
Severity: enhancement → normal
Priority: P2 → P1
Waiting for 14424 before able to see this working. I will checkin the dialogOverlay.xul code now, but we will not see it working until this other bug is fixed.
Blocks: 9685
No longer blocks: 9673
Target Milestone: M11 → M12
Moving to M12.
No longer blocks: 9685
Target Milestone: M12 → M13
Mass move to M13.
dividing up phillips qa contact bugs, he no longer works here
Whiteboard: 1 day to complete, week of 9/20-9/25
Joining cc list since it drives me batty not to be able to hit return in dialogs.
Blocks: 21868
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This is working for the most part now. There are only a few dialogs that are still broken. If one is found please log a bug against me and I will fix the broken cases individually. The underlying mechanisms are fixed.
Status: RESOLVED → REOPENED
Using the 1999122308 build, the implementation deviates from the expected results (e.g. how default buttons behave in 4.x, or any other OS.) Specifically, upon pressing "Return" to auto-press "OK" to close a dialog, the dialog closes, without giving any visual feedback that the "OK" button was pushed. Instead, the button (and dialog's) behavior should be similar to if the user had pressed the "OK" button. hangas, please let me know if you'd like this side-issue split into a separate bug, with this one closed out. Thanks!
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Yes, that is a different issue. I will mark this one fixed again and open a new bug for this issue.
Status: RESOLVED → VERIFIED
[Verified fixed. hangas broke the side-issue into bug #9635.]
Doh, I meant 22600.
You need to log in before you can comment on or make changes to this bug.