131007 - clicking in window while downloading PDF may freeze browser

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[lmcquarr]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
BuildID:    20020308003

This is a bug in the gecko engine since I can repo the bug in both mozilla and 
another client of the engine. 

When you have a full screen plug-in like Acrobat, and you click in the window 
while the PDF is loading (but not quite there), your app will "sort of" freeze:

 1- If you mouse over the browser menu items ... then are inactive.
 2 - If you attempt to select an Acrobat toolbar button or pull down the scroll 
bar in acrobat, nothing happens.
3 - If you left click, nothing happens.


The only way to unfreeze the app is:

1 - Cover it with another app and then uncover it.
2 - Right click! 

Using Spy,  I determined that the culprit window in the window hierachy was a 
MozillaWindowClass.  I have a snapshot of my spy window hierachy (ping me for 
it if you want it), or you can see
for yourself using these techniques:

1 - Start spy and get ready to duplicate the bug
2 - Select Messages in the Spy menu and then drag the little window
pointer in spy on top of the main browser window frame at the top
of the window hierachy.  You want to watch this window. 
3 - But you also want to watch all of its children, so check the checkbox for 
child windows.
4 - turn on watching any messages for WM_LBUTTONxx and WM_RBUTTONxx.
5 - Reproduce the bug
6 - Read the window handle of the window that is getting the WM_LBUTTONxx.  It 
is a MozillaWindowClass one a few levels deep in the
hierarchy.
7 - If you right click, the first click goes to this above window.
Click again, and finally, the messages will go to the Acrobat window.
For some reason, the right click makes things OK again (just like covering and 
uncovering the app)

I bet you need to look in the WndProc for the MozillaWindowClass!  I have some 
ideas based on bugs I have seen in other browsers.




Reproducible: Always
Steps to Reproduce:
1.Start Mozilla and the Acrobat Reader (5 or 5.05). 
2.Go to the above URL.  While it is downloading, click anywhere
in the blank window  (the above URL is designed to make sure that
none of the file shows up in Acrobat until it is completely downloaded ... so 
that you can easily repo this bug).
3. FREEZE time.  (Try to use mozilla toolbar, Acrobat tools, etc.

--------------

4 - Unfreeze by covering and uncovering the app or by right clicking. 

Actual Results:  Freeze

Expected Results:  Works just as if you had not clicked in the window. 

I will put a doctored up version of my spy hierachy in the attachments.

Comment 1

[Peter Lubczynski]

This sounds important, nominating nsbeta1

I think an MozillaWindowClass is a nsWindow and the WinProc can be found here:
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsWindow.cpp#1096

These messages eventually get dispatched to the static callback HandlePluginEvent
 in nsPluginViewer:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginViewer.cpp#523

I wonder if SetFocus() here is causing problems?

Comment 2

[lmcquarr]

Attachment: Spy window hierarchy for Mozilla showing the window Getting Messages

When the app is frozen, this is the window hierarchy showing the window that is
getting the messages.

Comment 3

[rubydoo123]

We need to qualify this before nsbeta1+ -- how frequent is this? Can we 
duplicate this? Is it specific to a particular type of pdf file?

Comment 4

[rubydoo123]

I did some more testing on this one, and I can reproduce this. At the point the 
app freezes, you can't even minimize the app. The only way to wake it up is to 
do as already reported -- overlay the app with another app window.

Very strange, it seems like some kind of focus thing is going off.

Comment 5

[Winnie Lam]

plusing as per adt plugins triage.  pdf's widely used... especially in banking
sites.

Comment 6

[rubydoo123]

adding priority and milestone

Comment 7

[av (gone)]

I can reproduce this too. You can also 'unfreeze' it by simply switching to
another window and going back, no need to cover with another window. This makes
getting stack trace tricky since you will need to switch to the DevStudio window
at which point things may get back to normal.

Comment 8

[Winnie Lam]

adding adt2 to status whiteboard as per discussion with beppe.  

Comment 9

[av (gone)]

We probable need help from event guru to explain what is going on here and how
to fix it right. I add saari.

This is closely related to events and hence not easy to debug. I wrote a little
helper which formats |nsGUIEvent.message| to a readable string and found the
following. When we click on a window with left mouse button the following
sequence of events comes to our plugin widget callback:

*** NS_PLUGIN_ACTIVATE
*** NS_GOTFOCUS
*** NS_MOUSE_LEFT_BUTTON_DOWN

Note that mouse event itself comes the last. NS_GOTFOCUS is probably a result of
us doing |widget->SetFocus()| explicitely.

After all this happens looks like portions outside the plugin window, say,
chrome, menu, toolbar do not respond to mouse movement, i.e. even if the mouse
pointer is over a menu item the mouse left click and mouse move messages still
go to the plugin window. The situation is different with mouse wheel message, it
goes as I would expect: to the plugin window when the cursor is over it and
elsewhere when it is not.

Here is what happens if user click on some other window to 'unlock' the browser:

*** NS_DEACTIVATE
*** NS_LOSTFOCUS

Here is the sequence of events after right mouse click on the plugin window
which  too 'unlocks' the browser:

*** NS_MOUSE_RIGHT_BUTTON_UP
*** NS_CONTEXTMENU

No focus messages are involved in the latter case, so I think focus itsel is not
an issue.

Comment 10

[Peter Lubczynski]

Just guessing, but what about something like this:

  nsCOMPtr<nsIEventStateManager> esm;
  if (NS_OK == aPresContext->GetEventStateManager(getter_AddRefs(esm))) {
    esm->SetContentState(this, NS_EVENT_STATE_FOCUS);
  }

Comment 11

[Peter Lubczynski]

Never mind, that probably doesn't work with full-page plugins.

Comment 12

[Peter Lubczynski]

This might be related to bug 144227?

Comment 13

[Peter Lubczynski]

This is either a dup or depends on Saari's fix in bug 82534.

Comment 14

[Paul Wyskoczka]

Please add adt1.0.1 after you have an s=/sr=.

Comment 15

[rubydoo123]

mass move PL RTM 

Comment 16

[av (gone)]

OK, after spending a lot of time looking at various messages coming in and out I
think that this is most likely a dup of bug 82534. That bug contains some
comments mentioning the same events I see here and think are relevant. There is
a patch in 82534 and it is claimed that it helps in some situations. It does not
help here unfortunately. Marking.

*** This bug has been marked as a duplicate of 82534 ***

Comment 17

[shrirang khanzode]

v

Comment 18

[av (gone)]

Not fixed :( Reopening.

Comment 19

[rubydoo123]

*** Bug 155441 has been marked as a duplicate of this bug. ***

Comment 20

[rubydoo123]

removing ADT marker and PL RTM marker, Andrei will continue t work this issue in
the next milestone

Comment 21

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 22

[rubydoo123]

This may be resolved when bug 90256, moving 1.4 beta - plug-in branch work

Comment 23

[Peter Lubczynski]

--->peterl

Comment 24

[Peter Lubczynski]

Attachment: patch v.1

Here's the fix: mouse capture was being left on. Turning it off seems to
unfreeze the browser.

Comment 25

[John Keiser (jkeiser)]

Comment on attachment 114128 [details] [diff] [review]
patch v.1

Hrm, who captured the mouse in the first place and why?  Do we do mouse capture
as a general rule?  (I didn't think we did ...)

Comment 26

[Peter Lubczynski]

Comment on attachment 114128 [details] [diff] [review]
patch v.1

this needs work: doesn't work for layout code path.

Comment 27

[Peter Lubczynski]

So here's what I'm seeing and why mouse capture is the culprit:

Setup:
a) We create our nsWindow, which has it's own WinProc
b) We pass the hWnd to Acrobat (in SetWindow) which subclasses it
c) Plugin code then again subclasses it such that PluginWinProc gets events first

Launch PDF, click in browser window while splash screen is up.

1) PluginWinProc get the WM_LBUTTONDOWN, dispatches to Acrobat WinProc
2) Acrobat then seems to dispatch this to our nsWindow's WinProc
3) In nsWindow's WinProc, we turn on mouse capture in WM_LBUTTONDOWN and turn
off mouse capture on WM_LBUTTONUP
4) PluginWinProc gets the WM_LBUTTONUP, dispatches to Acrobat WinProc
5) PROBLEM ---> nsWindow's WinProc does not get a WM_LBUTTONUP so its can't turn
off mouse capture!!!

Here's the log of windows events:
nsWindowWndProc msg: 21   (WM_MOUSEACTIVATE)
nsWindowWndProc msg: f    (WM_PAINT)
pluginWndProc msg: 20     (WM_SETCURSOR)
pluginWndProc msg: 20
pluginWndProc msg: 20
pluginWndProc msg: 201     (WM_LBUTTONDOWN)
nsWindowWndProc msg: 201
pluginWndProc msg: 20      
nsWindowWndProc msg: f
nsWindowWndProc msg: 14    (WM_ERASEBKGND)
pluginWndProc msg: 202     (WM_LBUTTONUP)
pluginWndProc msg: 200     (WM_MOUSEFIRST)
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 200
nsWindowWndProc msg: 200
nsWindowWndProc msg: 84     (WM_NCHITTEST)
pluginWndProc msg: 200
nsWindowWndProc msg: 200
nsWindowWndProc msg: 84
pluginWndProc msg: 200
nsWindowWndProc msg: 200
nsWindowWndProc msg: 84
pluginWndProc msg: 200
nsWindowWndProc msg: 200
nsWindowWndProc msg: 84
pluginWndProc msg: 200
nsWindowWndProc msg: 200
pluginWndProc msg: 1f        (WM_CANCELMODE)
nsWindowWndProc msg: 1f
pluginWndProc msg: 215       (WM_CAPTURECHANGED)
nsWindowWndProc msg: 215    
nsWindowWndProc msg: 86      (WM_NCACTIVATE)
nsWindowWndProc msg: 6       (WM_ACTIVATE)
nsWindowWndProc msg: 1c      (WM_ACTIVATEAPP)
nsWindowWndProc msg: 1c
nsWindowWndProc msg: 1c
nsWindowWndProc msg: 1c
nsWindowWndProc msg: 1c

Notice both nsWindow's WinProc and the plugin WndProc get a 201 (WM_LBUTTONDOWN)
but only the plugin's WinProc gets the 202 (WM_LBUTTONUP).

Possible Solutions:
A) We disable mouse capture for plugin windows. I've got a patch which this working.
B) Acrobat should either not pass us the WM_LBUTTONDOWN or needs to ensure it
also passes a WM_LBUTTONUP. 

Liz, any idea on why we only get one of these paired mouse events? Are you also
capturing the mouse?

Comment 28

[Peter Lubczynski]

Attachment: patch v.2

Because the plugin window proc does get all the events, this bug can also be
fixed if plugin code mimics the calls in ChildWindow::DispatchMouseEvent to
turn on/off capture on mouse events. That's what this patch does.

Comment 29

[John Keiser (jkeiser)]

Comment on attachment 115672 [details] [diff] [review]
patch v.2

Looketh good.

Comment 30

[Peter Lubczynski]

patch in trunk, marking FIXED.

Comment 31

[bmartin]

Marking Verified Fixed 
Unable to reproduce freezing the browser against latest Mozilla trunk ID: 2003051204

The test URL specified in the bug is no longer valid.

I tested against .pdf files posted on http://www.irs.gov
For example: http://www.irs.gov/pub/irs-pdf/i1040.pdf