Closed Bug 116766 Opened 23 years ago Closed 21 years ago

[windows] java and all other plugins flickers through active tab on resize because its child window is getting WM_PAINT or WM_WM_ERASEBKGND handled by DefWindowProc

Categories

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

x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: studer, Assigned: peterl-bugs)

References

()

Details

(Keywords: testcase, Whiteboard: [PL2:NA])

If you have loaded a page with a java plugin in it into a tab in the background
and  you resize the window, you see the java plugin flickering on the active page.

Steps to reproduce:
1. Load a page with a java plugin in it. I used the URL-Page
2. New Tab (ctrl+t)
3. Load any other page into this tab (let's take mozilla.org)
4. Resize the window.

Actual Results:
You see the java plugin flickering

Expected Results:
The java plugin should be completely invisible


I've chosen the Tabbed Browser as component. Please change if necessary...
Merry Christmas to the mozilla community!
Confirmed with JRE 1.4.0 Beta3.  WinMe, Win98SE, Win2k.   Reporter, what JRE 
are you using?
I first started seeing this problem around then time when I switched from 1.3.x 
to 1.4.x, but then again it could have been a change in Mozilla at around the 
same time.  (tabs, etc...)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm using JRE 1.3.1-b24

Sorry for the lack of this information...
is this still a problem when viewing in a regular, non-tabbed browser window?
No, this is only with tabs.   If a separate browser window is resized, then the
java applet will not "peek" through, as it's from a different window.
I don't think this is particularly a tabbed browser issue. You can't, for 
example, cover over a java applet with an opaque, absolutely positioned DIV,
either. 

It is an ugly effect when resizing tabbed browser windows, though.
jrgm, you think this should go to oji or layout, then?
Not oji. But I don't know whether it should go to layout or plugins or simply 
stay  with ~toolkit. Ask hyatt.
xp toolkit for the nonce, then. hyatt, punt as needed!
Component: Tabbed Browser → XP Toolkit/Widgets
QA Contact: sairuh → jrgm
The applet shines through on every repaint for a few milliseconds (sometimes too
short to be noticable). E.g. visit http://java.sun.com, don't scroll the page,
open one of the links in a different tab. If now the Java applet's paint method
is called to update it's canvas content, you can sometimes see it flickering
through the current page.

This will also explain why the applet shines through when you resize the browser
window, because evertime the browser window changes in size, the paint method of
the Java applet is called to redraw the applet.

Maybe not quite related to this bug, but I think if you switch to a different
tab, so the tab with the Java applet is a background tab, the Java applet should
be stopped by the browser (calling the applet's stop method), just like an
applet should be stopped if the browser window gets minimized. I mean why should
my PC waste plenty of CPU resources to render graphical applet output, that I'm
not going to see anyhow?

If I switch back to the tab with the applet, it can be started again by calling
the start method of the applet. This might be a dirty fix to prevent applets
from shining through when they update their canvas content as as long as the
canvas content doesn't change (and it won't once the applet was stopped) it also
won't be redrawn anymore. However, I don't know if it also prevents the applet
form shining through whenever the browser window is resized, but it doesn't make
much sense to repaint a stopped applet, so maybe it will circumvent the bug as a
whole.
Maybe roc or dbaron can help get this bug assigned to the right person.

/be
Can someone use spy++ to see whether the plugin's widget is actually on top of
the tab page? I would expect it to be behind the frontmost tab's widget, and
thus consistently invisible. Or is the Java plugin windowless?
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Depends on: 155771
Java is not windowless. 

Using Spy++, I'm seeing WM_PAINTs sent to Java's window, when we resize and it's
in a background tab. I'm still investigating how these are getting posted, but
it's not from the plugin API.
*** Bug 156702 has been marked as a duplicate of this bug. ***
-->over to me for investigation of why WM_PAINTs are getting to hidden child
plugin windows....
Assignee: hyatt → peterl
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → Plug-ins
Priority: -- → P2
QA Contact: jrgm → shrir
Summary: java plugin flickers through active tab on resize → java and other plugins flickers through active tab on resize because its child window is getting WM_PAINTs
Whiteboard: [PL2:NA]
Target Milestone: Future → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.0.2
Keywords: nsbeta1+
Target Milestone: mozilla1.0.2 → mozilla1.2alpha
Peter, what other plugins did you see this behaviour with?
Quicktime shows this behavior on window resize too. Testcase (behind firewall):
http://warp.mcom.com/u/peterlubczynski/testcases/plugins/quicktime5.html

We may end up having to re-subclass the widget to be able to stop all events. I
wonder if hiding the window directly makes a difference over hiding the parent?
Keywords: testcase
Blocks: 146015
No longer blocks: 146015
*** Bug 146015 has been marked as a duplicate of this bug. ***
*** Bug 162822 has been marked as a duplicate of this bug. ***
This is pretty bad and pretty easy to reproduce with any plugin. You can easily
reproduce even with the default plugin:
1. In Appearance Preferences, change the default background color to anything
but white
2. Load a testcase with this tag in a tab: <embed type="any/bogus/mime">
3. Switch to another tab such that the plugin is not visible and resize the main
browser window. Notice the white box outline of the default plugin flashes
though the tab and over your custom background color.

Plugins subclass our widget. Using Spy or setting a breakpoint in my plugin's
WinProc, I see a WM_NCPAINT followed by a WM_ERASEBKGND. The Microsoft Platform
SDK says that on WM_NCPAINT, the DefWindowProc function paints the window frame.
 Because these messages may be handled by DefWindowProc in plugins as they have
been in samples, I think that may be the problem. When I hack up my tester
plugin to always consume these messages, this bug stops happening but I get
other weird side effects when the plugin is actually visible. The plugin (or
plugin's window) does not "know" it's been hidden.

Thoughts? Ideas?

We can not expect plugin authors to change their code. I think we need to stop
these messages from getting to the plugin's window by either preventing their
dispatch or intercepting them by re-subclassing the window after the plugin.
Maybe the plugin's window isn't properly being told it's been hidden when a
parent is hidden? Here is the stack that leads up my plugin's WinProc recieving
WM_NCPAINT and WM_ERASEBKGND:

PluginWinProc(HWND__ * 0x00110582, unsigned int 133, unsigned int 1, long
USER32! 77d43a5f()
USER32! 77d49797()
USER32! 77d45874()
USER32! 77d458a4()
NTDLL! 77f5108f()
nsView::SetVisibility(nsView * const 0x02c86318, nsViewVisibility nsViewVi
nsViewManager::SetViewVisibility(nsViewManager * const 0x023ccf58, nsIVi
nsContainerFrame::SyncFrameViewAfterReflow(nsIPresContext * 0x023cc6b0
nsContainerFrame::FinishReflowChild(nsIFrame * 0x026b59fc, nsIPresContext
nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext * 0x
nsBoxToBlockAdaptor::DoLayout(nsBoxToBlockAdaptor * const 0x02c957d0,
nsBox::Layout(nsBox * const 0x02c957d0, nsBoxLayoutState & {...}) line 106
nsStackLayout::Layout(nsStackLayout * const 0x0258dd50, nsIBox * 0x02c72e
nsContainerBox::DoLayout(nsContainerBox * const 0x02c72eac, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x02c72eac, nsBoxLayoutState &
nsDeckFrame::DoLayout(nsDeckFrame * const 0x02c72eac, nsBoxLayoutState
nsBox::Layout(nsBox * const 0x02c72eac, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x02c1f558, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x02c1f558, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x02c1f558, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x02c1f1f0, nsBoxLayoutS
nsBoxFrame::DoLayout(nsBoxFrame * const 0x02c1f1f0, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x02c1f1f0, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x026cc6d4, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x026cc6d4, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x026cc6d4, nsBoxLayoutState & {...}) line 106
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x026cc5ec, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x026cc5ec, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x026cc5ec, nsBoxLayoutState & {...}) line 1062
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x026b5974, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x026b5974, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x026b5974, nsBoxLayoutState & {...}) line 106
nsSprocketLayout::Layout(nsSprocketLayout * const 0x02378328, nsIBox * 0x
nsContainerBox::DoLayout(nsContainerBox * const 0x02582c70, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x02582c70, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x02582c70, nsBoxLayoutState & {...}) line 106
nsStackLayout::Layout(nsStackLayout * const 0x0258dd50, nsIBox * 0x02582a
nsContainerBox::DoLayout(nsContainerBox * const 0x02582a84, nsBoxLayout
nsBoxFrame::DoLayout(nsBoxFrame * const 0x02582a84, nsBoxLayoutState &
nsBox::Layout(nsBox * const 0x02582a84, nsBoxLayoutState & {...}) line 106
nsBoxFrame::Reflow(nsBoxFrame * const 0x02582a4c, nsIPresContext * 0x02
nsRootBoxFrame::Reflow(nsRootBoxFrame * const 0x02582a4c, nsIPresConte
nsContainerFrame::ReflowChild(nsIFrame * 0x02582a4c, nsIPresContext * 0x0
ViewportFrame::Reflow(ViewportFrame * const 0x02582a10, nsIPresContext *
PresShell::ResizeReflow(PresShell * const 0x023cd880, int 11085, int 8490) lin
PresShell::ResizeReflow(PresShell * const 0x023cd884, nsIView * 0x023cd198
nsViewManager::SetWindowDimensions(nsViewManager * const 0x023ccf58, 
nsViewManager::DispatchEvent(nsViewManager * const 0x023ccf58, nsGUIE
HandleEvent(nsGUIEvent * 0x0012e668) line 83
nsWindow::DispatchEvent(nsWindow * const 0x023cd234, nsGUIEvent * 0x00
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012e668) line 1055
nsWindow::OnResize(nsRect & {...}) line 4984 + 15 bytes
nsWindow::ProcessMessage(unsigned int 71, unsigned int 0, long 1239988, lon
nsWindow::WindowProc(HWND__ * 0x0024038e, unsigned int 71, unsigned i
USER32! 77d43a5f()
USER32! 77d49797()
USER32! 77d45874()
USER32! 77d4962b()
NTDLL! 77f5108f()
DocumentViewerImpl::SetBounds(DocumentViewerImpl * const 0x0237b3b0, 
nsDocShell::SetPositionAndSize(nsDocShell * const 0x00b1cccc, int 0, int 0, in
nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012edf0) line 434
nsWindow::DispatchEvent(nsWindow * const 0x00afa0a4, nsGUIEvent * 0x00
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012edf0) line 1055
nsWindow::OnResize(nsRect & {...}) line 4984 + 15 bytes
nsWindow::ProcessMessage(unsigned int 71, unsigned int 0, long 1241916, lon
nsWindow::WindowProc(HWND__ * 0x0032030c, unsigned int 71, unsigned i
USER32! 77d43a5f()
USER32! 77d49797()
USER32! 77d45874()
USER32! 77d4962b()
NTDLL! 77f5108f()
nsXULWindow::SetPositionAndSize(nsXULWindow * const 0x00b2e748, int 5
nsChromeTreeOwner::SetPositionAndSize(nsChromeTreeOwner * const 0x00b
nsResizerFrame::HandleEvent(nsResizerFrame * const 0x02afee6c, nsIPresCon
PresShell::HandleEventInternal(nsEvent * 0x0012f864, nsIView * 0x02b02940,
PresShell::HandleEvent(PresShell * const 0x023cd884, nsIView * 0x02b02940,
nsViewManager::HandleEvent(nsView * 0x02b02940, nsGUIEvent * 0x0012f8
nsView::HandleEvent(nsViewManager * 0x023ccf58, nsGUIEvent * 0x0012f86
nsViewManager::DispatchEvent(nsViewManager * const 0x023ccf58, nsGUIE
HandleEvent(nsGUIEvent * 0x0012f864) line 83
nsWindow::DispatchEvent(nsWindow * const 0x023cd234, nsGUIEvent * 0x00
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f864) line 1055
nsWindow::DispatchMouseEvent(unsigned int 300, unsigned int 1, nsPoint * 0x
ChildWindow::DispatchMouseEvent(unsigned int 300, unsigned int 1, nsPoint *
nsWindow::ProcessMessage(unsigned int 512, unsigned int 1, long 36963039, l
nsWindow::WindowProc(HWND__ * 0x0024038e, unsigned int 512, unsigned 
USER32! 77d43a5f()
USER32! 77d43b2e()
USER32! 77d43d6a()
USER32! 77d441fd()
nsAppShellService::Run(nsAppShellService * const 0x00ab9370) line 452
main1(int 3, char * * 0x002a73c8, nsISupports * 0x00000000) line 1509 + 32 b
main(int 3, char * * 0x002a73c8) line 1873 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
Summary: java and other plugins flickers through active tab on resize because its child window is getting WM_PAINTs → [windows] java and all other plugins flickers through active tab on resize because its child window is getting WM_PAINT or WM_WM_ERASEBKGND handled by DefWindowProc
*** Bug 156286 has been marked as a duplicate of this bug. ***
moving to 1.3 beta
Target Milestone: mozilla1.2alpha → mozilla1.3beta
nsbeta1-. Peter is overloaded with higher priority issues.
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.3beta → Future
This bug has been fixed. I don't see the problem anymore. Marking WFM.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.