Closed
Bug 600187
Opened 14 years ago
Closed 14 years ago
Fields in Google Apps are sometimes created without focus (and can't receive focus without switching away)
Categories
(Camino Graveyard :: HTML Form Controls, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: web, Assigned: stuart.morgan+bugzilla)
References
()
Details
(Keywords: regression)
Attachments
(4 files, 2 obsolete files)
21.98 KB,
image/png
|
Details | |
87.82 KB,
text/plain
|
Details | |
54.33 KB,
application/octet-stream
|
Details | |
4.22 KB,
patch
|
stuart.morgan+bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.2.11pre) Gecko/20100926 Camino/2.1a1pre (like Firefox/3.6.11pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.2.11pre) Gecko/20100926 Camino/2.1a1pre (like Firefox/3.6.11pre) I was going to say this is an intermittent bug but I am now able to reproduce it 100% of the time (at least, tonight I can...). Steps to reproduce: 1. Be in Gmail 2. Click on calendar 3. Click somewhere on your calendar to make a new meeting 4. Get a popup without focus that is unfocusable (ie. you can't click in the text field to make it focus) If #4 isn't clear, see the attached - I single clicked where the '01:00' is and this is the popup that results - that slot in calendar was empty/white before I clicked; all the UI displayed (green + dialog box) is the result of the single click. The text field does not have focus and will not receive focus, ie. clicking in it is ignored. It will receive focus if you tab through (about 20-30 items) and once it has received focus, the bug doesn't happen again (ie. you need to close that window and then repeat from #2 to reproduce). An easy work around is to switch away (Cmd-Tab) and then switch back to Camino, and the redraw event (?) fixes the problem. I realise the Google HTML/CSS/js already pushes the bounds of reasonable web coding so this may not be an easy bug to find or fix, but since I now have a debug build of Camino, I'm willing to work a little harder at finding this bug (eg. turning on some traces or dumping or something similar) so I can report what/where it's happening? Reproducible: Always Steps to Reproduce: Steps to reproduce: 1. Be in Gmail 2. Click on calendar 3. Click somewhere on your calendar to make a new meeting 4. Get a popup without focus that is unfocusable (ie. you can't click in the text field to make it focus) Actual Results: Text field can't receive focus Expected Results: Text field should (a) receive focus and (b) already have focus
Reporter | ||
Comment 1•14 years ago
|
||
Sorry, forget to attach pic
Comment 2•14 years ago
|
||
This sounds a lot like bug 581491, but since we have supposedly 100% reproducible steps here and a reliable testcase, maybe we should forward-dupe that other bug. cl
Can anyone else reproduce this? I can't :( Nathan: one thing you can do if you can reproduce this in your debug build is to look for Console spam from right around the time this happens; there might be some assertions that fire or something. (Note the logging is buffered, so it won't all appear in the Console immediately; you'll have to check the approximate timestamp, do some other things, and then look in that region of the log for output with the approximate times, some of which may be interleaved with later-timestamped messages.)
Comment 4•14 years ago
|
||
:sigh: I can't reproduce it either :-(. Nathan, can you also test this with a default profile - using TroubleShoot Camino. http://pimpmycamino.com/parts/troubleshoot-camino
Reporter | ||
Comment 5•14 years ago
|
||
1. Apologies, I should've checked for previous bugs better (I searched for 'google focus' but not just 'field focus' or similar. Tired brain at night :P 2. I cannot reproduce this with TroubleShoot Camino, which probably explains why Smokey and Philippe can't reproduce it! 3. I've extracted the Camino-relevant bits from my console when I did this (in my non-troubleshoot Camino :-) and it has some assertion statements and other stuff, which I've attached. I removed the URLs because I don't know how much Google is URL-session based. 4. In doing this, I observed an interesting fact - if I Cmd-Tab away and back *before* doing the click, it fixes the behaviour, ie. the faulty JavaScript interpretation (?) [ form handling ] happens in the base page, rather than the popup window. ie. if you application switch between steps #2 and #3 in 'steps to reproduce', the subsequent popup (#3/#4) appropriately has/receives focus.
Comment on attachment 479304 [details]
Log of Camino-based console messages (URLs censored)
Wow, that's extremely noisy, far more than I expected.
I wonder if
WARNING: Nothing to handle this event!: 'frame', file /Users/removed/build/camino/mozilla/layout/base/nsPresShell.cpp, line 6158
WARNING: Subdocument container has no frame: file /Users/removed/build/camino/mozilla/layout/base/nsDocumentViewer.cpp, line 2383
are related to this problem?
Attachment #479304 -
Attachment mime type: application/octet-stream → text/plain
Reporter | ||
Comment 7•14 years ago
|
||
If it helps, here's the contrasting file - a console log of me doing the same thing in my 'Troubleshoot Camino.app', where the bug doesn't happen. Hopefully some kind of diff between these two logs shows the problem area?
Reporter | ||
Comment 8•14 years ago
|
||
Interestingly, there is no 'Nothing to handle this event' or nsPresShell.cpp in this log, but there are three 'Subdocument container has no frame' / nsDocumentViewer.cpp references
Comment 9•14 years ago
|
||
Nathan, what setting do you have for Camino > Preferences > Tabs - 'Links that would open new windows' ? Is it checked ? I just tested, and in that case (pref checked), I can seem indeed to repro the bug - but you *must* come from Gmail and click calendar in Gmail. In that case, it probably is the same issue as noted in the forums http://forums.mozillazine.org/viewtopic.php?p=9954461#p9954461 and subsequent posts. Here is a very minimal testcase that seems to repro the issue: http://dev.l-c-n.com/camino/target/target_blank.html
Reporter | ||
Comment 10•14 years ago
|
||
1. Yes, I have 'Links that would open new windows' checked 2. The minimal testcase above reproduces the issue for me (= that's exactly what happens in Google) 3. Unchecking 'Links that would open new windows' fixes the problem 4. Turning JavaScript off does *not* seem to fix the problem for me (= still no focus/unfocusable with JS off Looks like this is a duplicate/corollary of 576821.
Comment 11•14 years ago
|
||
Ok, I'll confirm this as new then, as we have good STR and a test case. regression range (tested on 10.6): fails Version 2.1a1pre (1.9.2.6pre 20100624001536) Camino changeset: bcec097daed8 Core changeset: c6843f08a56f works Version 2.1a1pre (1.9.2.6pre 20100623001330) Camino changeset: 0c56464434af Core changeset: 8ac0dfc2a34a http://hg.mozilla.org/camino/pushloghtml?fromchange=0c56464434af&tochange=bcec097daed8 ce88f8c24e83 Stuart Morgan — Bug 563321: Work around focus regression when creating new tabs. sr=pink
Assignee | ||
Comment 12•14 years ago
|
||
I'll try to spend some time with gdb and figure out what I broke.
Assignee: nobody → stuart.morgan+bugzilla
Flags: camino2.1?
Stuart thinks maybe this is worse than bug 563321, so we might want to back that one out for a1 if we can't find a better way to fix focus.
Flags: camino2.1a1?
Assignee | ||
Comment 14•14 years ago
|
||
The problem with my previous fix is that (as I learned while fixing the nasty Google Calendar bug), page/script-opened windows don't go through out URI loading--Gecko takes care of it internally--so loadURI:... was never called, and my last attempt at working around the changes was thus a failure in this case. This moves the handling to onLocationChange, which seems to be the first callback we get where presShell is available. Since CHBrowserView can no longer handle this internally I made the API reflect the current Gecko behavior, and had our wrapper handle the new behavior, instead of creating a multi-class (CHBrowserView + CHBrowserListener) hack that would be more confusing.
Attachment #500710 -
Flags: superreview?(mikepinkerton)
Assignee | ||
Comment 15•14 years ago
|
||
Oops, forgot to remove the now-unused BOOL.
Attachment #500710 -
Attachment is obsolete: true
Attachment #500711 -
Flags: superreview?(mikepinkerton)
Attachment #500710 -
Flags: superreview?(mikepinkerton)
Comment 16•14 years ago
|
||
Comment on attachment 500711 [details] [diff] [review] v2 + [mBrowserView setActive:YES]; can this fail too? is it worth checking before blindly setting pending activation to NO? sr=pink
Attachment #500711 -
Flags: superreview?(mikepinkerton) → superreview+
Assignee | ||
Comment 17•14 years ago
|
||
I can't swear it can't fail; figuring out where presShell is actually populated in core is non-trivial. In my tests it was always available at that point. Just checking that it worked before setting the pending activation to NO won't help unless I also add more handling at other callbacks, which I'd rather not do without evidence that it's needed. I think for now I'll just add debug logging if it fails, and if we have more focus problems we can test with a debug build to quickly see if it needs tweaking.
Assignee | ||
Comment 18•14 years ago
|
||
Same as v2, but with added debug logging, as I'll check it in.
Attachment #500711 -
Attachment is obsolete: true
Attachment #500790 -
Flags: superreview+
Assignee | ||
Comment 19•14 years ago
|
||
Landed http://hg.mozilla.org/camino/rev/88e1573864ce
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: camino2.1a1?
Flags: camino2.1a1+
Flags: camino2.1?
Flags: camino2.1+
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•