Closed Bug 131007 Opened 19 years ago Closed 18 years ago

clicking in window while downloading PDF may freeze browser


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

Windows 2000





(Reporter: lmcquarr, Assigned: peterl-bugs)




(Keywords: topembed+, Whiteboard: [PL:BRANCH][Acrobat]custrtm-)


(2 files, 1 obsolete file)

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
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.
This sounds important, nominating nsbeta1

I think an MozillaWindowClass is a nsWindow and the WinProc can be found here:

These messages eventually get dispatched to the static callback HandlePluginEvent
 in nsPluginViewer:

I wonder if SetFocus() here is causing problems?
Keywords: nsbeta1
Summary: Clicking in Window Why Doanloading Sort Of Freezes App → clicking in window while downloading PDF may freeze browser
When the app is frozen, this is the window hierarchy showing the window that is
getting the messages.
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?
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.
plusing as per adt plugins triage.  pdf's widely used... especially in banking
Keywords: nsbeta1nsbeta1+
adding priority and milestone
Priority: -- → P2
Target Milestone: --- → mozilla1.0
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.
adding adt2 to status whiteboard as per discussion with beppe.  
Whiteboard: [ADT2]
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:


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:


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


No focus messages are involved in the latter case, so I think focus itsel is not
an issue.
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);

Never mind, that probably doesn't work with full-page plugins.
This might be related to bug 144227?
Whiteboard: [ADT2] → [ADT2][PL RTM]
Keywords: adt1.0.0
Whiteboard: [ADT2][PL RTM] → [ADT2][PL RTM],custrtm-
This is either a dup or depends on Saari's fix in bug 82534.
Depends on: 82534
No longer depends on: 82534
Depends on: 82534
Please add adt1.0.1 after you have an s=/sr=.
Keywords: adt1.0.0
Whiteboard: [ADT2][PL RTM],custrtm- → [ADT2 RTM][PL RTM],custrtm-
mass move PL RTM 
Target Milestone: mozilla1.0 → mozilla1.0.1
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 ***
Closed: 18 years ago
No longer depends on: 82534
Resolution: --- → DUPLICATE
Depends on: 82534
Not fixed :( Reopening.
Resolution: DUPLICATE → ---
Whiteboard: [ADT2 RTM][PL RTM],custrtm- → [ADT2 RTM][PL RTM][Acrobat]custrtm-
*** Bug 155441 has been marked as a duplicate of this bug. ***
removing ADT marker and PL RTM marker, Andrei will continue t work this issue in
the next milestone
Whiteboard: [ADT2 RTM][PL RTM][Acrobat]custrtm- → [PL2:NA][Acrobat]custrtm-
Target Milestone: mozilla1.0.1 → mozilla1.0.2
Severity: critical → major
Severity: major → normal
Target Milestone: mozilla1.0.2 → mozilla1.2alpha
batch: adding topembed per Gecko2 document
Keywords: topembed
Keywords: topembedtopembed+
Blocks: grouper
This may be resolved when bug 90256, moving 1.4 beta - plug-in branch work
Depends on: 90256
Whiteboard: [PL2:NA][Acrobat]custrtm- → [PL:BRANCH][Acrobat]custrtm-
Target Milestone: mozilla1.2alpha → mozilla1.4beta
Assignee: av → peterl
Attached patch patch v.1 (obsolete) — Splinter Review
Here's the fix: mouse capture was being left on. Turning it off seems to
unfreeze the browser.
Attachment #114128 - Flags: superreview?(kin)
Attachment #114128 - Flags: review?(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 on attachment 114128 [details] [diff] [review]
patch v.1

this needs work: doesn't work for layout code path.
Attachment #114128 - Attachment is obsolete: true
Attachment #114128 - Flags: superreview?(kin)
Attachment #114128 - Flags: review?(jkeiser)
So here's what I'm seeing and why mouse capture is the culprit:

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?
Attached patch patch v.2Splinter Review
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.
Attachment #115672 - Flags: superreview?(bryner)
Attachment #115672 - Flags: review?(jkeiser)
Comment on attachment 115672 [details] [diff] [review]
patch v.2

Looketh good.
Attachment #115672 - Flags: review?(jkeiser) → review+
Attachment #115672 - Flags: superreview?(bryner) → superreview+
patch in trunk, marking FIXED.
Closed: 18 years ago18 years ago
QA Contact: shrir → bmartin
Resolution: --- → FIXED
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
For example:
You need to log in before you can comment on or make changes to this bug.