68004 - error when giving a window focus - hard to reproduce

Status: VERIFIED WORKSFORME

(SeaMonkey :: UI Design, defect)

Description

[Christopher Blizzard (:blizzard)]

Occasionally when I load pages I get JS errors.  Reloads usually take care of
this error but I think that it's strange that this happens.  Has anyone else
seen this?

I wonder if it's related to the problem that I see sometimes where a page is
loaded and the spacebar in form controls will scroll the page.  Reloading when
that happens usually fixes the problem.

And, bonus, these are all intermittent problems.

JavaScript error: 
chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no
properties

JavaScript error: 
chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no
properties

JavaScript error: 
chrome://navigator/content/navigator.js line 921: _content.focus is not a function

Comment 1

[Boris Zbarsky [:bzbarsky]]

I think I have a way of reproducing it (3 out of 3 tries so far):

1) go to the "bugs reported today" page (not sure this is necessary)
2) scroll down to bug 68007 and middle-click to open it in new window
3) middle click on the "url" link to open the page the bug is reported against
in a new window
4) while the page opened in #3 is loading, middle click on the link to bug 67796
in the third comment.

That creates this problem.

Comment 2

[Christopher Blizzard (:blizzard)]

I've discovered through the school of hard knocks that this bug shows up really
easily on a debug linux build.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I've been seeing this a lot in the last few days' builds.  Usually takes no more
than 10 minutes of browsing for _something_ to trigger it.

When I see this problem, the window affected can't pop up view source (and
sometimes can't pop up javascript alerts), and opening links in a new window
stops working (either with middle-click or from context menu).  This makes the
browser quite difficult to use.

Comment 4

[Christopher Blizzard (:blizzard)]

I get this a lot when opening a url from mail/news into an already open window.

Comment 5

[Brendan Eich [:brendan]]

I see what blizzard sees, all the damn time.  I'm on Linux -- maybe that
matters?  I always click on mail links and let them dogpile on the first browser
window, and that reproducibly leaves that window in the busted state.  Someone
debug and fix this (you're welcome to co-debug on my machine), please!

BTW, I just got the window into a better state (view source from context menu
works, space bar pages down, page up/down and arrow keys work) by typing into
this text area and moving focus back to the content area.  Just clicking on the
content area was not enough (never is).

/be

Comment 6

[Brendan Eich [:brendan]]

Cc'ing saari, this may be a toolkit bug (dup?).

/be

Comment 7

[Christopher Blizzard (:blizzard)]

Brendan, when you say that you see this all the time are you talking about the
problem where space down triggers a page down or something else?

Comment 8

[Brendan Eich [:brendan]]

blizzard: yes, and view source doesn't work, and page up/down and arrow keys
don't work.  I just noticed this in my console after clicking on your bug mail's
link and having the first browser window get focus and raise:

chrome://navigator/content/navigator.js line 926: focusedWindow has no properties

Maybe this helps (I hope my sources aren't too out of date -- I'm running my own
build with parts as old as 25-Jan).

/be

Comment 9

[Christopher Blizzard (:blizzard)]

I wouldn't worry about being out of date.  This has been around for a long time.

Comment 10

[Brendan Eich [:brendan]]

Unlike bzarsky, however, I can click on links in the newly-loaded, existing
window that mail targets when I click on a link (linkified text) in a message. 
But view source from the context menu does nothing, space bar is useless, etc.

/be

Comment 11

[Christopher Blizzard (:blizzard)]

Sounds like focus problems to me.  Has anyone ever seen this on anything other
than linux?

I'm wondering if it's something related to focus changes and url loading. We do
a focus() when we finish loading a url.  I wonder if it also has to do with
clicking on the window just before that focus() call comes in from the docshell.
 That might cause problems - you click on a window causing a focus in and then a
focus call comes in right in the middle.

The more that I think about it the more that I think there is some room for
error in there knowing how the gtk code works...

Comment 12

[Fabian Guisset]

Brendan : what you are seeing about keyboard arrows, spacebar, pgup&down not
working is another bug that has been around for as long as I can remember, and I
could never find a good bug for it. I never got around to file it either.
I nominate this for 0.9 cuz it's driving some people completly crazy.

Comment 13

[R.K.Aa.]

bug 67442 "'open link in new window' doesn't work all the time" gives error
message about chrome://communicator/content/contentAreaUtils.js line 31:
contentFrames has no properties

It displays both opening new window by middle-click and context menu, and when
changing focus.

I think this one is a dup.

Comment 14

[Matthias Versen [:Matti]]

I see this with build 2001021204.

How to reproduce for me : 
Go to the "CVS Checkin" page. Open a few bug links (5-7) 
with "Open Link in New Window". 
open a link, switch back to the original window and open the next bug ....)
Go now to one of the opened bugs and try to open on link in this bug with 
"Open Link in New Window".
If I see this error in the console, I can´t open new links in new windows.
I must restart mozilla !

This is a regression and should be fixed for M0.8 !

Comment 15

[Boris Zbarsky [:bzbarsky]]

possibly related to this is bug 65398.  At least that repeatably triggers the
ontentAreaUtils.js line 31 error.

Comment 16

[saari (gone)]

blizzard, your theory about mid-event sequence interruption would cerainly cause
this. I'm adding printfs to my linux build to see if I can get an event sequence
trace when this happens.

Comment 17

[saari (gone)]

YES! I *finally* have a reproducable test case!!!

From mail message, click on a bugzilla link. As soon as the browser window comes
forward in the window manager start wailing on the space bar. When the page
finishes loading you'll be at the bottom of the page and in the annoying space
to scroll mode. Now I just have to fix it...

Comment 18

[Christopher Blizzard (:blizzard)]

Please let me know if and when you find it.  Dammit, as I'm filling in this form
right now the page is jumping all over the place.

If it is a gtk bug please let me know if you can figure out the event sequence.
 I can probably fix it once I know what it's supposed to be doing.

Comment 19

[Christopher Blizzard (:blizzard)]

People might want to look at bug #67988.  I'll bet they are related.  Please
don't mark it as a dup until I can actually prove it, though.

Comment 20

[saari (gone)]

We're not firing activate in all cases on linux from the gtk widget code. The
cases where things work correctly are the ones when
nsWindow::DispatchActivateEvent gets properly called. If activate doesn't get
dispatched the focus tracker semaphore doesn't unlock and focus never gets
properly set to the text field.

Comment 21

[Christopher Blizzard (:blizzard)]

It used to be that sending activate events from every focus in event would cause
all hell to break lose.  When are those supposed to be sent?

I try to send them whenever a toplevel window is given focus right after the
focus event is dispatched.

Comment 22

[Johan Bucht]

I'm seeing this in win98, using build 2001-02-13 04.
Looks like a focus problem to me.

Comment 23

[Christopher Blizzard (:blizzard)]

Wow, that's new.  I thought this was linux only.

Comment 24

[saari (gone)]

"I try to send them whenever a toplevel window is given focus right after the
focus event is dispatched."

That sounds right to me, but for some reason in this case I don't see the
activate come through.

Comment 25

[Christopher Blizzard (:blizzard)]

A missing NS_ACTIVATE event would be caused by the problem that I have a patch
for in #67988.

Comment 26

[Christopher Blizzard (:blizzard)]

The fix for #67988 has been checked in.  I'll bet this is fixed because of it. 
Give it a try with my patch in it.

Comment 27

[Johan Bucht]

Looks like the problem has disapperar with that patch.
Downloaded build 2001-02-21 05 and I have not seen it any more.

Comment 28

[Boris Zbarsky [:bzbarsky]]

still seeing the 

chrome://communicator/content/contentAreaUtils.js line 31: contentFrames has no
properties

message.  When it appears, open link in new window does not work, page source
cannot be brought up, page info is blank.

Is this a separate problem?

Comment 29

[Yoshiki Yazawa]

I made modificatin on contentAreaUtils.js line 72:

-      newWin = window.openDialog( getBrowserURL(), "_blank", "chrome,all,dialog
=no", url, charsetArg, true );
+      newWin = window.openDialog( getBrowserURL(), "_blank", "chrome,all,dialog
=no", url );

and line 75:

-      newWin = window.openDialog( getBrowserURL(), "_blank", "chrome,all,dialog
=no", url, null, true );
+      newWin = window.openDialog( getBrowserURL(), "_blank", "chrome,all,dialog
=no", url );

It is not fix for this problem, but it cures, I think.
Does it help determination of cause?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Yoshiki, those lines are the way they are because that fixes bug 53549.  And
this problem predates the checkin that modified those lines (they were changed
on 2001-02-28)

Comment 31

[Yoshiki Yazawa]

Boris, you are confused. On 2001-02-08, Blake added only last (boolean)
argument of openDialog(). 

I removed *both* last argument and 5th argument. 5th (charsetArg) argument 
already exists on ver 1.1. (See Bonsai.)

I don't think this is "fix" for this problem, but do think it points out that 
5th argument of openDialog() concerns the line 31 problem.

Comment 32

[R.K.Aa.]

could the checkin for bug 67079 cause this bug? I don't find it hard to repro at
all - just open a few links in new window and change focus between old/new
windows back and forth a little fast while content loads. New window will loose
track of what and where it is, spawning the errors observed here. (as mentioned
before - The same horked "windowstate" leads to bug 67442)

It doesn't have to do with clicking on the window btw - i focus them via WM's
"raise on mouseover".

Comment 33

[Viswanath Ramachandran]

nav pretriage: we need to find a better owner for this than Vishy :). 

Comment 34

[Paul Chen]

nav triage team:

Someone should nail this once and for all. Marking nsbeta1+, mozilla0.9.2, 
reassigning to pchen

Comment 35

[Paul Chen]

nav triage team:

Saari, can you take this? Looks like you know what's going on. Reassigning to 
saari. Resetting target milestone

Comment 36

[saari (gone)]

Are we still seeing this? I just played around with it trying to reproduce and
couldn't.

Comment 37

[Colin Phillips]

The WFM on 2001080921 under Linux.  I never see any JS errors.  Is this still an
issue?

Comment 38

[John Morrison]

I haven't seen these errors in some time. Marking WFM, and someone can reopen
if they have a positive sighting. :-/

Comment 39

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)