Closed Bug 12674 Opened 21 years ago Closed 11 years ago

Command Updating & Dispatching


(Core :: XUL, defect, P3)






(Reporter: trudelle, Unassigned)



(Keywords: meta)

Tracking bug, see dependency tree.
Depends on: 12408, 12635
Blocks: 12659
on 10/30/99, Saari wrote:

I pulled clean on all my machines, built and verified that things worked
before my changes. Then I took all my changes on each platfrom and forward
merged them. Works fine on MacOS, works fine on Windows (no more crashing),
waiting for Linux build to finish.

So. Things are fine, it just took me another 2 days to verify that. <sigh>
No reply from joki on my questions, but I changed the code to do what I
thought was the right thing, and it seems much happier now. I'm going need
code reviews from a bunch of people, so this probably won't make it in
until Monday, but it looks like it is in good shape.

I keep getting mails from people like buster to the effect of "hey, I hear
you're working on focus and will you fix <insert their problem here>". My
stuff will fix some of these problems but not all. Opening a dialog without
focus is his particular problem. Rod seems to think I can fix Gecko's
problems with tabbing through forms and focus. So I'm guessing that this
general "focus" task is going to be one of those infinitely growing tasks
as more people shove related bugs at me. I don't know if I'm the right
person to fix these, but I guess I'm as good as any at this point.

Here are the things that will still need to be solved after my checkin.

- Remove nsIFocusableContent from HTML elements and replace it with the new
CSS user-focus attribute. The new focus work is using the new CSS way, but
I didn't retrofit all of layout yet as I'm trying to stage this work into
more manageable chunks. This is not required for the command dispatcher,
and is purely an enhancement. Category: right thing to do.

- Keeping track of the currently focused chain of elements. Necessary for
proper resetting of focus after you deactivate/reactivate a window, and to
prevent repetive firing of focus/blur events in the content model. It works
mostly correctly with my new code, but still fires repetitive blur/focus
events through the DOM. This is still better behavior than the current tip,
much closer to dogfood.

- Editor needs dialogs to be able to popup and not steal focus. This work
would half fall on me, and half on Dan. I'd have to huddle with Dan about
this, but it should be "easy", depending on how cooperative the OSes are.
Buster thinks this is dogfood.

- Random focus bugs in layout. Tabbing in forms, scrolling to tab-focused
elements that are off screen, etc.
mass-moving all m13 bugs to m14
giving me rest of phillips open qa contact bugs, sorry for spam
Due to Beta indication in Summary, putting beta1 into keyword field.
Keywords: beta1
Adding meta keyword.
Keywords: beta1meta
Whiteboard: [PDT-]
mass migration to m15, to get off m14 radar
Target Milestone: M14 → M15
*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to

QA Contact: paulmac → jrgm
Mass-moving M15 meta/tracking bugs to M16
Target Milestone: M15 → M16
Summary: [BETA] Command Updating & Dispatching → Command Updating & Dispatching
Whiteboard: [PDT-]
Target Milestone: M16 → M22
Moving meta (tracking) bugs to M22
Mass moving all of my open Nav/toolkit bugs to new owner.
Assignee: trudelle → sgehani
Assignee: samir_bugzilla → nobody
QA Contact: jrgmorrison → xptoolkit.widgets
Whiteboard: [worksforme?]
Command updating has been working for a while (if I understand the intent of this bug)
Closed: 11 years ago
Resolution: --- → WORKSFORME
Whiteboard: [worksforme?]
You need to log in before you can comment on or make changes to this bug.