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)
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
Reporter | ||
Comment 2•23 years ago
|
||
I'm using JRE 1.3.1-b24 Sorry for the lack of this information...
Comment 3•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
jrgm, you think this should go to oji or layout, then?
Comment 7•23 years ago
|
||
Not oji. But I don't know whether it should go to layout or plugins or simply stay with ~toolkit. Ask hyatt.
Comment 8•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
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?
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 12•22 years ago
|
||
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.
Comment 13•22 years ago
|
||
*** Bug 156702 has been marked as a duplicate of this bug. ***
Comment 14•22 years ago
|
||
-->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
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → mozilla1.0.2
Comment 15•22 years ago
|
||
Peter, what other plugins did you see this behaviour with?
Comment 16•22 years ago
|
||
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
Comment 17•22 years ago
|
||
*** Bug 146015 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 162822 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
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
Comment 20•22 years ago
|
||
*** Bug 156286 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
nsbeta1-. Peter is overloaded with higher priority issues.
Comment 23•21 years ago
|
||
This bug has been fixed. I don't see the problem anymore. Marking WFM.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•