User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082105 Minefield/3.0a8pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082105 Minefield/3.0a8pre When returning from the AutoComplete ListView of the Location bar, focus gets lost, and one has to tab to the Search textbox and back to the location bar to get it back. Reproducible: Always Steps to Reproduce: 1. Start MineField. 2. Press Control+L to focus the Location bar. 3. Start typing the URL of a site you previously visited, for example bugz (beginning of bugzilla.mozilla.org). 4. Press DownArrow. The AutoComplete ListView appears, selecting the URL and title of the first match. 5. Press RightArrow to accept the AutoComplete and continue to type a part after the .org/ portion. Actual Results: Focus now moves to an invisible multi-select ListBox that has no selected item. Pressing any Arrow key will now not result in any speech at all. Expected Results: Focus should return to the Location bar EditCombo where one could continue typing the address after the auto-completed URL portion. This regressed from Firefox 2.0. In Firefox 2.0, instead of the ListView, a menu had been used for the AutoComplete. When pressing RightArrow, the caret and focus would properly return to the EditCombo.

Evan, do you see this problem on Linux?

Aaron, it appears to be a Windows only problem. It broke on July 22, 2007. The July 22 build was OK, the July 23 build from 05:00 A.M. first shows this behaviour. Here are the checkins for that time period: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-22+00%3A00&maxdate=2007-07-23+06%3A00&cvsroot=%2Fcvsroot

On Linux, event log for "focus" on nightly build of 2007-07-22: focus(0, 0, None) ------- press "Ctrl + L" source: [autocomplete | Location] application: [application | Minefield] focus(0, 0, None) source: [entry | Location] application: [application | Minefield] focus(0, 0, None) -------- press down arrow source: [table cell | http://bugzilla.mozilla.org/] application: [application | Minefield] focus(0, 0, None) ---------- press right arrow source: [entry | Location] application: [application | Minefield] Event log for "focus" on nightly build of 2007-07-23: focus(0, 0, None) ------- press "Ctrl + L" source: [autocomplete | Location] application: [application | Minefield] focus(0, 0, None) source: [entry | Location] application: [application | Minefield] focus(0, 0, None) ------- press down arrow source: [table cell | http://bugzilla.mozilla.org/] application: [application | Minefield] focus(0, 0, None) ------- press right arrow source: [entry | Location] application: [application | Minefield] focus(0, 0, None) source: [tree table | ] application: [application | Minefield] We can see, an additional focus event on |tree table| was fired on 2007-07-23 build.

Evan, can you find out where the broken code is and submit a patch or assign it to the person who broke it?

This bug was exposed after bug 387496's check-in. I think it's actually a regression of bug 279703. Collapsed popup menu now has state INVISIBLE but not COLLAPSED.

er.. when I was changing the product field of this bug from "firefox" to "core", the flag "blocking-firefox3" was cleared automatically. I didn't find where I can reset it. Aaron, please reset it if needed. Sorry about that.

Evan, do not calculate state for containerAccessible twice.

blocking-firefox3 flag is for Firefox bug not Core bug we can ask "blocking1.9" if necessary.

Comment on attachment 278359 [details] [diff] [review] patch > // Only fire focus event if it is not inside collapsed popup >- if (State(containerAccessible) & nsIAccessibleStates::STATE_COLLAPSED) >+ if (State(containerAccessible) & nsIAccessibleStates::STATE_COLLAPSED || >+ State(containerAccessible) & nsIAccessibleStates::STATE_INVISIBLE) > return NS_OK; As Surkov said, why would you get the state twice? In fact, you can even avoid an extra &/if, when you do something like: const kMenuClosedStates = nsIAccessibleStates::STATE_COLLAPSED | nsIAccessibleStates::STATE_INVISIBLE; if (State(containerAccessible) & kMenuClosedStates)) { return NS_OK; } Also, why doesn't it expose STATE_COLLAPSED anymore? Shouldn't we really be fixing that as well?

Well, after dug deeper, I found this is actually an old bug, not regression of bug 279703. We didn't set STATE_COLLAPSED in nsXULMenupopupAccessible::GetState(): 613 if (!isActive) 614 *aState |= (nsIAccessibleStates::STATE_OFFSCREEN | 615 nsIAccessibleStates::STATE_INVISIBLE); So we can either to check STATE_INVISIBLE in "DOMMenuItemActive" event handling, or to assign STATE_COLLAPSED to closed menupopup.

/cvsroot/mozilla/accessible/src/xul/nsXULMenuAccessible.cpp,v <-- nsXULMenuAccessible.cpp new revision: 1.63; previous revision: 1.62 done

patch backed out because of tree closed. reopen.

checked in.

Reopening this one because it is the cause of bug 395400. Verified this by backing out the patch for this bug and recompiling: Context menus are once again read properly.

Yes, that's what caused it Adding STATE_COLLAPSED was the right thing to do, but we're incorrect that the menu is collapsed/invisible etc: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/accessible/src/xul&command=DIFF_FRAMESET&root=/cvsroot&file=nsXULMenuAccessible.cpp&rev1=1.62&rev2=1.63

I'm closing this in favor of bug 395400 -- there's a patch in that bug which fixes the new problem. It's not really the fault of this bug, it's because we don't calculate state collapsed correctly.