576821 - Focus lost when loading 'resolved' bug pages in bugzilla.m.o.

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Accessibility, defect)

Description

[philippe (part-time)]

Bug pages that are marked as resolved (fixed, duplicate, invalid, etc) lose focus when loaded via a link from within b.m.o.

The following conditions must be true:
1. set 'Tab Selects' to 'all form controls and links' in Camino prefs
2. log in to bugzilla.m.o
3. have 'saved searches' to display in the footer of b.m.o pages
   (bugzilla preference page)
   - 1 saved search is enough, e.g. the default config of 'My Bugs'

STR
1. load bug 570314
2. click on the link in comment 0 to the other bug (bug 561957)

AR: paging down fails (spacebar / page down key), tabbing fails.

The issue is not limited to the bug in the STR above, loading a bug list page and following a link to a 'resolved' bug will do.

This is pretty weird, as only 'resolved' bugs are affected. Scanning through the (generated) html, I cannot find any difference that might explain this.
If I'm not logged in everything works peachy…

I tried the same on the WebKit bugzilla pages, but could not reproduce.

Camino 2.0.x has no problems. All Gecko-1.9.2 based Camino builds are affected.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I still can't reproduce this even now that things are back to normal here.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If you disable JS, does focus still get lost?  /me grasping at straws…

Comment 4

[Mehmet]

(In reply to comment #3)
> If you disable JS, does focus still get lost?

Smokey, I tried it with "disabled" Java Script with the link in my Bug 577059 .

Result: Delete/Backspace works perfect after disabling JS !!!

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

To summarize from irc:

philippe confirmed that JS off does "solve" the problem in his case, too.

I can reproduce Mehmet's testcase with a fresh profile in a release build (but not a debug build), both the delete and space-for-page-up/down.

In debug builds, it doesn't reproduce, but we do get 

^G###!!! ASSERTION: no document available: '0', file /Users/smokey/Camino/dev/192branch/Camino192Branch/camino/src/formfill/KeychainService.mm, line 1215
WARNING: NS_ENSURE_TRUE(childCount == 1) failed: file /Users/smokey/Camino/dev/192branch/Camino192Branch/camino/src/history/HistoryDataSource.mm, line 629

and also possibly

WARNING: NS_ENSURE_SUCCESS(rv, 0) failed with result 0x8000FFFF: file /Users/smokey/Camino/dev/192branch/mozilla/content/base/src/nsContentUtils.cpp, line 2756

I still can't reproduce philippe's case in a release build, and a debug build continues to corrupt my Keychain when I try to log in to Bugzilla (I was going to check for Console spam there, too).

Comment 6

[philippe (part-time)]

Here is another variant of the same issue (although it is not 100% reproducible):

1. bookmark http://www.bbc.co.uk/news/
2. switch to the BM manager and double click on the BBC bookmark
3. page loads, try scrolling with spacebar or page down key or go back with the 'delete' key.

result: fail

Loading the same page from a link, or from the location bar, or from the BM bar works correctly.

I suspect the ticker/scrolling thingie near the top of the page somehow swallows the focus when it loads (once the rest of the page has loaded). Removing it (#ticker {display: none !important;}) solves the issue.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I wonder if this is the same/similar thing as the bug Stuart fixed on the safebrowsing overlay just before 2.0 (and which I can't find right now), in that we're getting a new NSView and the one we've already focused has become hidden?  At least in the BBC case, I'd bet pre-Gecko 2, the ticker gets its own child widget, which IIRC are NSViews/ChildViews.

(Also, I wonder, if that does happen to be the case, could we have some general-purpose code that checks to see if the view that has first responder status is hidden and does the reset dance?  I can't remember what the safebrowsing fix code does, i.e. if it's general-purpose or not, since I can't find the bug :( .)

One other thing to look at, probably with the Google Code case since I think that HTML will be the simplest, is to get the generated (DOM) source of the page with the JS on and compare it to the generated source with JS off (which I think should be identical to actual view-source, but I'm not sure).

Comment 8

[philippe (part-time)]

(In reply to comment #7)
> I wonder if this is the same/similar thing as the bug Stuart fixed on the
> safebrowsing overlay just before 2.0 (and which I can't find right now), in
> that we're getting a new NSView and the one we've already focused has become
> hidden?  At least in the BBC case, I'd bet pre-Gecko 2, the ticker gets its own
> child widget, which IIRC are NSViews/ChildViews.

Bug 522422 I think.

Comment 9

[philippe (part-time)]

http://dev.l-c-n.com/camino/b576821 contains source vs generated source for a google code page and the BBC page (js is turned on).

For the google code page, the only difference I found (aside of significant code rewrite making diff pretty useless) is an additional div at the bottom of the generated source page. Obviously, that div doesn't appear in the JS OFF case.
That div is what pops up when clicking on the 'My favorites' at the top of the page. It is generated in this script (halfway down, after running it through jsbeautifier):
http://www.gstatic.com/codesite/ph/8688443596719512860/js/core_scripts_20081103.js

nothing remarkable about the contents of that div, except the way it makes it into the page.

Obviously, when loading the gen_source page, this bug is not present (the problem element is already in the source).

---
In both pages (google code and BBC), the offending element is styled with 'overflow:hidden'. That implies, in Gecko 1.9.2 a child widget, I think. By itself - that is, in a static page - this doesn't cause problems

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Any change here since Stuart landed bug 600187?

Comment 11

[Mehmet]

(In reply to comment #10)
> Any change here since Stuart landed bug 600187?

I can still reproduce it (from my comment 4 = Bug 577059).

Camino Version 2.1a1pre (1.9.2.14pre 20110105001147)

Comment 12

[philippe (part-time)]

(In reply to comment #10)
> Any change here since Stuart landed bug 600187?

Sadly, no :-(.

Eventually, it got slightly worse. The case outlined in comment 6 (loading a page by double-click in the BM manager) is now reproducible for all and any page - even the most static one.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If someone has some time, playing with the patch from bug 522422 might be useful.

In particular, backing out the change entirely, but also just removing the && [mBrowserView isBlockedErrorOverlayShowing] condition from the |if|, like so:

+ if (newResponder == [self window] && oldResponderIsGecko) {
+   [[self window] makeFirstResponder:[mBrowserView browserView]];