Closed Bug 466332 Opened 16 years ago Closed 15 years ago

window:activate event missing for the Firefox Preferences dialog effective the 11 Oct build

Categories

(Core :: Disability Access APIs, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiggs, Assigned: ginnchen+exoracle)

References

(Blocks 1 open bug)

Details

(Keywords: access, fixed1.9.1, regression)

Attachments

(1 file)

Steps to reproduce:

1. Launch Accerciser and turn on event monitoring for window events
2. Launch Firefox
3. Get into the Preferences dialog

Expected results: A window:activate event would be emitted for the Preferences dialog

Actual results: A window:activate event is not emitted for the Preferences dialog

This issue was introduced in the 11 Oct build.
Within this timeframe, we had the following bugs addressed/backed out:
Bug 453591
Bug 457369 (backout, Windows-Only, had to do with iSimpleDomNode interfaces)

Suspicious maybe:
Bug 450554
See http://hg.mozilla.org/mozilla-central/shortlog/3762e6244e63
(In reply to comment #1)
> Within this timeframe, we had the following bugs addressed/backed out:
> Bug 453591

this one is backed out, right?

> Bug 457369 (backout, Windows-Only, had to do with iSimpleDomNode interfaces)

what's wrong with this bug?
(In reply to comment #2)
> (In reply to comment #1)
> > Bug 453591
> this one is backed out, right?

Not according to the bug itself, and I certainly didn't back that one out, no.

> > Bug 457369 (backout, Windows-Only, had to do with iSimpleDomNode interfaces)
> what's wrong with this bug?

See comment#8 in that bug, it explains why. I had to back it out on the same day you checked it in because it breaks JAWS on a wide scale.
Marco, sorry, I mixed questions. So now the question is what's wrong with the bug 453591?
(In reply to comment #4)
> Marco, sorry, I mixed questions. So now the question is what's wrong with the
> bug 453591?

I do not know if there is anything wrong with it at all. It is just one of the bugs that was checked in between the October 10 and October 11 builds, as Joanie points out in her description this bug starts happening on October 11. However, bug 450554, which has something to do with popups and panels, was also checked in in this time range, it could very well be that, or yet another bug that we haven't found yet. I was just trying to filter those that looked up-front like they are either in a11y code, or could have something to do with this.

So, no specific blame, just a hint about what was happening on that day. :-)
Flags: blocking1.9.1?
Ping. :-)

The impact of this bug for the user is that when you get into and then move around within the Preferences dialog, you have no speech and no braille because we get no events letting us know that this window has been activated. While one can Alt+Tab out of and back into the dialog as a workaround, it's hard to know that this needs doing if you can't see what's on the screen. :-)

It would, therefore, be awesome if this could be addressed sooner rather than later. Thanks much in advance!!!
Marco, is there a way to view the complete changeset between the Oct 10th and Oct 11th builds in module accessible?
Not yet, Timeless is working on enhancing HG queries to be able to do that. Aaron was asking about this exact same thing a few days ago, and Timeless said he would incorporate this feature.
Joanie,

I can reproduce this issue on HEAD. But I didn't reproduce it with 20081013 build on Linux.

Can you double check the regression date?

Thanks.
(In reply to comment #9)
> Joanie,
> 
> I can reproduce this issue on HEAD. But I didn't reproduce it with 20081013
> build on Linux.
> 
> Can you double check the regression date?
> 
> Thanks.

oops, my bad.
We need to workaround Bug 460926 before testing it.

The regression is caused by
changeset:   20244:0e52c4677cb4
user:        Neil Rashbrook <neil@parkwaycc.co.uk>
date:        Fri Oct 10 10:36:41 2008 +0100
summary:     Bug 365467 Focus contollers initial window and element can get out of sync r+sr=jst
CC'ing Neil to ask for any thoughts on this.
Blocks: 365467
Neil,

Here's the stack of opening pref dialog.

@1 (l@1) stopped in CheckForFocus at line 2301 in file "nsPresShell.cpp"
 2301       return;
(dbx 36) where 20
current thread: t@1
=>[1] CheckForFocus(aOurWindow = 0x85c2628, aFocusController = 0x8fd0cb8,
aDocument = 0x9841770), line 2301 in "nsPresShell.cpp"
  [2] PresShell::UnsuppressAndInvalidate(this = 0x90800d0), line 4321 in
"nsPresShell.cpp"
  [3] PresShell::UnsuppressPainting(this = 0x90800d0), line 4348 in
"nsPresShell.cpp"
  [4] DocumentViewerImpl::LoadComplete(this = 0x90514c0, aStatus = 0), line
1020 in "nsDocumentViewer.cpp"
  [5] nsDocShell::EndPageLoad(this = 0x96b2718, aProgress = 0x96b272c, aChannel
= 0x8ee2120, aStatus = 0), line 5164 in "nsDocShell.cpp"
  [6] nsWebShell::EndPageLoad(this = 0x96b2718, aProgress = 0x96b272c, channel
= 0x8ee2120, aStatus = 0), line 1013 in "nsWebShell.cpp"
  [7] nsDocShell::OnStateChange(this = 0x96b2718, aProgress = 0x96b272c,
aRequest = 0x8ee2120, aStateFlags = 131088U, aStatus = 0), line 5069 in
"nsDocShell.cpp"
  [8] nsDocLoader::FireOnStateChange(this = 0x96b2718, aProgress = 0x96b272c,
aRequest = 0x8ee2120, aStateFlags = 131088, aStatus = 0), line 1235 in
"nsDocLoader.cpp"
  [9] nsDocLoader::doStopDocumentLoad(this = 0x96b2718, request = 0x8ee2120,
aStatus = 0), line 854 in "nsDocLoader.cpp"
  [10] nsDocLoader::DocLoaderIsEmpty(this = 0x96b2718), line 763 in
"nsDocLoader.cpp"
  [11] nsDocLoader::OnStopRequest(this = 0x96b2718, aRequest = 0x8e89d88, aCtxt
= (nil), aStatus = 0), line 679 in "nsDocLoader.cpp"
  [12] nsLoadGroup::RemoveRequest(this = 0x99042e8, request = 0x8e89d88, ctxt =
(nil), aStatus = 0), line 688 in "nsLoadGroup.cpp"
  [13] nsDocument::DoUnblockOnload(this = 0x9841770), line 7008 in
"nsDocument.cpp"
  [14] nsDocument::UnblockOnload(this = 0x9841770, aFireSync = 1), line 6955 in
"nsDocument.cpp"
  [15] nsBindingManager::DoProcessAttachedQueue(this = 0x8f580f8), line 981 in
"nsBindingManager.cpp"
  [16] nsRunnableMethod<nsBindingManager>::Run(this = 0x98cdfb8), line 264 in
"nsThreadUtils.h"
  [17] nsThread::ProcessNextEvent(this = 0x80b77b8, mayWait = 1, result =
0x8046c10), line 510 in "nsThread.cpp"
  [18] NS_ProcessNextEvent_P(thread = 0x80b77b8, mayWait = 1), line 227 in
"nsThreadUtils.cpp"
  [19] nsBaseAppShell::Run(this = 0x8445df8), line 170 in "nsBaseAppShell.cpp"
  [20] nsAppStartup::Run(this = 0x8493788), line 182 in "nsAppStartup.cpp"

Perhaps we should SetFocusedWindow in PresShell::UnsuppressAndInvalidate()
What do you think?
The problem arises when a window has more than one nsPresShell, since none of them know which one needs to be focused. Instead, as I recall, the NS_GOTFOCUS event dispatched by the widget code should call SetFocusedWindow for you.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
nsWindow.cpp got the OnContainerFocusInEvent event.
But if the got focus event at line 2458 didn't send out activate event.
It failed to send at line 2465.

 2457       // dispatch a got focus event
 2458       DispatchGotFocusEvent();
 2459   
 2460       // send the activate event if it wasn't already sent via any
 2461       // SetFocus() calls that were the result of the GOTFOCUS event
 2462       // above.
 2463       if (mActivatePending) {
 2464           mActivatePending = PR_FALSE;
 2465           DispatchActivateEvent();
 2466       }

The reason is it couldn't get root accessible.
The reason of that is nsWebShellWindow::HandleEvent doesn't deal with NS_ACCESSIBLE_EVENT sent by nsWindow::DispatchActivateEvent.
Looking at the comments here, I'm assuming that the same issue is taking place in Thunderbird. If it's a different issue/bug, I'll investigate further and open a new bug.

(From a bug report filed against Orca by a user)

Please describe the problem:
When using thunderbird 3.0b1 orca does not respond to dialog boxes appearing.
These dialog boxes are ones such as the send message confirmation dialog box
when using the control+enter hotkey. Neither speech or braille show that this
dialog appears.

Steps to reproduce:
1. Ensure that thunderbird 3.0b1 is set to show confirmation dialog when
sending using hotkey.
2. Write a new message
3. Press control+enter to send the message

Actual results:
Orca does nothing, braille continues to show the text which was shown before
pressing the control+enter hotkey and speech says nothing.

Expected results:
Orca braille output would display the send button of the dialog box (as this is
what would have focus) and speech would read the dialog box.

Does this happen every time?
Happens every time I have done it.

Other information:
I believe that the dialog boxes do actually get focus because when I press
space then the send button is activated (send is the default button with
focus), or if I press shift+tab and then space then I go back to the message
(this corresponds to navigating to the cancel button and pressing it, orca is
not speaking this navigation of the dialog either). Other dialog boxes are
affected, eg. the confirmation of exit writer window dialog (the one which asks
whether you want to save the message) and I think the thunderbird preferences
dialog is equally affected. This only seems to happen on thunderbird 3.0b1, it
certainly wasn't present on thunderbird 3.0a3.
Attached patch patchSplinter Review
Neil, do you think it is the right fix?
Attachment #357925 - Flags: review?(neil)
I'd love to believe it works for you, but, even with the aid of a debugger, I was unable to trigger that code path.

(Note that the patch contains trailing whitespace on line 18.)
To trigger the code path, you need to enable a11y on GNOME.
(If you're using GNOME 2.24, you need to update at-spi to 1.24.1, or take the workaround in
https://bugzilla.mozilla.org/show_bug.cgi?id=460926#c4 )

The code path will be triggered on opening preference dialog.

You'd better run debugger through ssh, the keyboard input may be blocked when it breaks.
(In reply to comment #18)
> To trigger the code path, you need to enable a11y on GNOME.
Silly me, I'd forgotten to look at the platform.
Assignee: nobody → ginn.chen
Comment on attachment 357925 [details] [diff] [review]
patch

OK, so the reason this isn't a problem on the Windows platform is that the accessibility event is sent from the focused window which is actually a child of the top-level native window, and therefore has its accessible event sent via the view manager to the pres shell. So it seems reasonable to forward the event from the web shell window to the pres shell.
Attachment #357925 - Flags: review?(neil) → review+
Attachment #357925 - Flags: superreview?(roc)
Attachment #357925 - Flags: superreview?(roc) → superreview+
http://hg.mozilla.org/mozilla-central/rev/de843ab11f43

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b42b29ee809b
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Sorry to be a dunce :-( ... which version/build of Firefox wil this fix appear in?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: