615064 - Opening message in new window gives extra window:activate events making orca screen reader loose track of focus

Status: RESOLVED WONTFIX

(Thunderbird :: Message Reader UI, defect)

Description

[Michael Whapples]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101106 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14pre) Gecko/20101127 Lanikai/3.1.7pre

If I get a message to open in a new window then multiple window:activate events are sent out through at-spi. This means that when opening a message in a new window, the orca screen reader will loose track of the focus and the user will have to manually bring focus back to the message area. This problem can be observed back in thunderbird 3.1 up to the build mentioned for this bug report. I tried with the thunderbird 3.3 prerelease nightly build an this bug is not observed.

The orca bug report relating to this issue can be found at http://bugzilla.gnome.org/show_bug.cgi?id=633186

While it may be possible for orca to work around this issue, there may be cases where these extra window:activate events may not be possible to solve in orca (see further information below).

I have filed this bug against thunderbird as I am certain of what is occurring and can guarantee reproducing it. However I suspect it may be more of a core issue as I notice with firefox from my distribution's repository which uses XUL 1.9.2.12 that if I have pages open in a new window, and while having firefox already open, if I launch firefox again from gnome-terminal firefox gives a window:activate event despite not being the currently active window and so confusing orca again. If it is a core issue feel free to move it to that category.

Reproducible: Always

Steps to Reproduce:
1. Set thunderbird to open messages in a new window.
2. Launch a tool which will listen for events through at-spi (the orca screen reader will show the affect of the extra event and if orca is debugging you will see the additional event in the debug output).
3. Open a message in a new window.
Actual Results:  
multiple window:activate events can be observed, the second one makes orca loose track of the focus.

Expected Results:  
Only the first window:activate event should have been given.

Comment 1

[Ludovic Hirlimann [:Usul]]

Marco can you confirm this ?

Comment 2

[Fernando Herrera]

Confirmed: with ff3 window:activate is sent twice for the new window, but with ff4 it is sent only once.

Comment 3

[alexander :surkov (:asurkov)]

Thanks, Fernando.

No work for Fx 3.6 is planned and I would like to avoid it due to lack of resources. Also I don't think we will be allowed to land the patch into branch even if we had it. I think it should be wontfix.

Comment 4

[Michael Whapples]

(In reply to comment #3)
> Thanks, Fernando.
> 
> No work for Fx 3.6 is planned and I would like to avoid it due to lack of
> resources. Also I don't think we will be allowed to land the patch into branch
> even if we had it. I think it should be wontfix.

Could I ask what the situation is regarding thunderbird 3.1.x as this bug affects that as well? Firefox 4.0 is in beta so I hope the final release will come soon, but thunderbird 3.3 is only at a1 so I imagine might be some time off for users who use final releases (either due to sticking with distribution packages or because they want stable versions).

Comment 5

[alexander :surkov (:asurkov)]

I bet this requires core changes (not pure comm-central fix) and is targeted to Gecko 1.9.2 what is pretty much closed for non security/crashes fixes.

Comment 6

[Michael Whapples]

(In reply to comment #5)
> I bet this requires core changes (not pure comm-central fix) and is targeted to
> Gecko 1.9.2 what is pretty much closed for non security/crashes fixes.

I am not sure precisely how you define the different priorities for bugs but here is how I view things (much from the angle of a user)
* Fixing this would be corrective, what is observed to be happening simply should not occur.
* At best this can be misleading, it allows users to do things which simply should not be possible. As an example, with firefox (I have it set so pages open in a new window rather than new tab) I can have firefox open, then I may launch from a gnome-terminal firefox again with a page. The result is firefox tells orca it is the active window when it isn't and so orca allows me to use orca's navigation keys to read the page and interact with it (including links), but should I use a firefox key stroke obviously this doesn't lead to firefox taking it as its not active and so the currently active application may do something in response to the keypress.

While it may not crash mozilla applications, it certainly makes mozilla applications difficult for other software, particularly assistive technologies like orca and could potentially cause them to behave unpredictably.

Comment 7

[alexander :surkov (:asurkov)]

Michael, I realize it's very annoying and really bad bug. The same time it doesn't sound critical. I think the question I will be asked by drivers is why is this fix urgent now while Firefox 3.6 was shipped almost year ago.

Marco, what do you think?

Comment 8

[Marco Zehe (:MarcoZ)]

Alexander, i agree with you it is very unlikely we'd be allowed to land this fix now if we had one. But since we don't even have one, and we're running low on resources as is, Firefox 4 is our top priority. We'd only be allowed to land fixes for Gecko 1.9.2, which Thunderbird 3.1 and Firefox 3.6 are based on, if a) this would cause a crash or b) pose a security risk of malicious code being injected into Firefox or Thunderbird. Since none of this is the case, I bet drivers' response will be no.

Michael, you must realize that fixing this would not mean backporting something from the Mozilla 2.0 branch that Firefox 4 and Thunderbird 3.3 will be based on. This code has close to nothing to do with the code in Gecko 1.9.2 any more, since we refactored huge parts of it over the past year and fixed the bug alongside others. So developing a fix would mean developing it from scratch for Gecko 1.9.2. Doing this for getting a no for an answer would be a waste of resources we simply cannot afford.

Comment 9

[alexander :surkov (:asurkov)]

Marking wontfix per comment #8 at least until someone gets ready to narrow down the problem and convince drivers it's worth to take a fix on Gecko 1.9.2.

Comment 10

[Michael Whapples]

OK, I understand about the priorities being on gecko 2.0 applications.

Now talking from the angle of a user, this bug does cause me a number of issues and as thunderbird 3.3 isn't just round the corner (there is likely to be a number of development releases before the final release) it means that distribution supplied thunderbird packages will be affected by this bug for some time. In contrast I imagine firefox 4.0 final isn't far off so for that I probably would let it be.

So my question is: Is it worth me doing any further work into finding a fix as a fix would certainly be desirable as a thunderbird user? What are the chances of such a fix being accepted if I were to find one?

As to the question of, if such a fix was so important, why has the bug only been filed now? Again I think its a matter of priorities with the orca/gnome accessibility developers. Then speaking for myself, although I have probably been observing some of the affects of this bug for sometime, there are a number of affects it causes depending on the situation and so it was quite hard to clearly define what it was as a pure user. I have recently (last couple of months) really started digging into orca debug files to find out what its doing and what causes it. Its only been by digging into orca debug files that I was able to clearly define what was happening and still find it a little difficult to properly explain what is observed for some of the affects.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #10)

> So my question is: Is it worth me doing any further work into finding a fix as
> a fix would certainly be desirable as a thunderbird user? What are the chances
> of such a fix being accepted if I were to find one?

I think first of all you need to figure out whether a fix for bug like this can be accepted for the branch at all, for that it's worth to chat with drivers on #developers. If drivers thumb up for this bug then further decision whether the fix will be accepted or not depends on the fix itself.