Closed Bug 409083 Opened 17 years ago Closed 16 years ago

Incorrect scrollbar rendering with X-Lite plugin

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: vlad.alexander, Assigned: roc)

References

(
URL
)

Details

(Keywords: qawanted) 

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

We are a plug-in vendor for Firefox. We noticed that FF3b2 sometimes renders scroll bars in the wrong place when our plug-in is loaded on the page. This was not a problem in FF 2.

Here is a screen shot of correct rendering:
http://misc.xstandard.com/mozilla/good.gif

Here is a screen shot of incorrect rendering:
http://misc.xstandard.com/mozilla/bad.gif

Notice the scroll bars above the plug-in.

The behavior is intermittent. On some pages it happens after a POST. On other pages it happens the first time the page is rendered.

Reproducible: Sometimes

Steps to Reproduce:
1. Install our plug-in from:
http://xstandard.com/download/x-lite.dmg
(when prompted to reboot, ignore and just close that window)

2. Quit and re-start FF3b2

3. Go to http://xstandard.com/test.asp

4. Press Submit button several times to reproduce the problem. For us, the problem is reproducible after the first time the Submit button is pressed. Then to reproduce this again, you may need to press the Submit button several times or re-start the browser and try again.



This issue is reproducible on PowerPC and Intel platforms.
Version: unspecified → Trunk
I was unable to reproduce this bug given the testcase above in both FF3b2 and FF3b3pre (buildid: 2008011704). I realize that its listed as "Sometimes," but there has to be a limit as to what's reproducible "maybe" and when it should be considered not reproducible.

Vlad, is these a testcase you could provide that's more reliable? Maybe you could try getting a build of b3pre and starting with a clean profile, then try reproducing the bug on your end.

As of right now, though, I recommend this bug for WORKSFORME.
I installed a nightly build 2008012104 Minefield/3.0b3pre and the bug is still there. The bug is classified as "sometimes" reproducible but it occurs about 30% of the time our plug-in is loaded in FF after a POST. This is a serious bug because our users will stop using our software if this bug is not fixed.

Make sure you are running a "release" build of FF as opposed to "debug" build.

Also, with the plug-in installed, try loading this page:
http://xstandard.com/en/test-drive/pro/separating-content-from-formatting/

For us, the bug is reproducible the _first_ time this page loads. You need to quit the browser (or open a new window) and load this page. You should see plug-in's scroll bars rendered in the wrong place.

Bryan, can I ask you to try this on several computers or ask a colleague to try to reproduce this bug. This issue is very important to us. Thank you in advance.

Ok, Vlad. I'm able to reproduce the rendering problem in trunk with that new page you linked above.

Moving bug out of General into Core->Layout: Form Controls, confirming, and switching your URL. Please make sure you use _trunk_ for any testing you do, not specifically b3pre as I said earlier (terminology mistake on my part). Trunk builds are located here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/.

Some more notes: I'm able to reproduce this in trunk (build info below) only on the first instance of loading the page (which appears to be when the plugin itself loads).

Buildid: 2008012204 on Mac OS 10.5.1 or 10.5.2 9C20
URL: http://xstandard.com/test.asp → http://xstandard.com/en/test-drive/pr...
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.form-controls
Summary: Rendering problem in FF3b2 → Incorrect scrollbar rendering with X-Lite plugin
I doubt very much that this is form control issue.  roc, want to take a look?

Bryan or Vlad, would you be willing to hunt down a trunk regression range for this using the builds from http://archive.mozilla.org ?  That is, the two nightly builds between which this broke.  That would help a lot in tracking down what change caused the problem.
Assignee: nobody → roc
Component: Layout: Form Controls → Layout: View Rendering
Keywords: qawanted
QA Contact: layout.form-controls → ian
Flags: blocking1.9?
I'll see if I can track a range down later tonight, Boris, but I won't be able to get to it until then.
This appears to be the first build where the problem is reproducible:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/04/2007-04-11-04-trunk/

For us, it happens more often on this test page:

http://xstandard.com/test.asp

On this test page, enter multiple lines of text in the editor until the editor generates a vertical scroll bar. Then press Submit button. The page will refresh. You may need to press the Submit button several times to reproduce the incorrect rendering of the scroll bars.
There is a comment next to a range of bugs that reads "Draw native scrollbars using nsITheme on Mac OS X". There is a good chance that this might be related to this bug.
Ah, indeed.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
This appears to actually *not* be our nsNativeThemeCocoa::DrawScrollbar code. I set a breakpoint there and we don't hit it at all during a problematic reload.
The random scrollbars are definitely being painted by the plugin (although it could still be our bug, of course). The rectangle defined by the two scrollbars seems to be the same as the plugin's size.

I'm pretty sure this is the stack:

Breakpoint 2, 0x92e6c796 in HIScrollBar::DrawSelf ()
#0  0x92e6c796 in HIScrollBar::DrawSelf ()
#1  0x92e1c027 in HIView::DrawCacheOrSelf ()
#2  0x92e1be27 in HIView::SendDraw ()
#3  0x92ed8417 in HIView::RecursiveDrawNonComposited ()
#4  0x92ed7bde in HIView::DrawNonComposited ()
#5  0x92e1ba20 in HIView::Draw ()
#6  0x92e171e8 in HIView::Show ()
#7  0x92e5f4d7 in ShowControl ()
#8  0x3be01c31 in CBelusXEditorCtrl::HandleEvent ()
#9  0x3bd69cd1 in CPlugin::HandleEvent ()
#10 0x3bd69d18 in NPP_HandleEvent ()
#11 0x3a349765 in ns4xPluginInstance::HandleEvent (this=0x3a066210, event=0xbfffbbbc, handled=0xbfffbbb8) at /Users/roc/mozilla-trunk/modules/plugin/base/src/ns4xPluginInstance.cpp:1271
#12 0x17fe7223 in nsPluginInstanceOwner::Paint (this=0x3bad4450, aDirtyRect=@0xbfffbcd0) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:3610
#13 0x17fe726f in nsObjectFrame::PaintPlugin (this=0x3c9081d0, aRenderingContext=@0x3c260b20, aDirtyRect=@0xbfffbcd0) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:1200
#14 0x17fe72b6 in PaintPlugin (aFrame=0x3c9081d0, aCtx=0x3c260b20, aDirtyRect=@0xbfffbcd0, aPt=@0xbfffbc58) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:1029
#15 0x1865f134 in nsDisplayGeneric::Paint (this=0x2564c34, aBuilder=0xbfffbd54, aCtx=0x3c260b20, aDirtyRect=@0xbfffbcd0) at /Users/roc/mozilla-trunk/layout/generic/../base/nsDisplayList.h:837
#16 0x17f36c39 in nsDisplayList::Paint (this=0x2564c78, aBuilder=0xbfffbd54, aCtx=0x3c260b20, aDirtyRect=@0xbfffbcd0) at /Users/roc/mozilla-trunk/layout/base/nsDisplayList.cpp:294
#17 0x17f37e3d in nsDisplayWrapList::Paint (this=0x2564c6c, aBuilder=0xbfffbd54, aCtx=0x3c260b20, aDirtyRect=@0xbfffbcd0) at /Users/roc/mozilla-trunk/layout/base/nsDisplayList.cpp:691
#18 0x17f38a9c in nsDisplayClip::Paint (this=0x2564c6c, aBuilder=0xbfffbd54, aCtx=0x3c260b20, aDirtyRect=@0xbfffc09c) at /Users/roc/mozilla-trunk/layout/base/nsDisplayList.cpp:883
#19 0x17f36c39 in nsDisplayList::Paint (this=0xbfffbfd4, aBuilder=0xbfffbd54, aCtx=0x3c260b20, aDirtyRect=@0xbfffc09c) at /Users/roc/mozilla-trunk/layout/base/nsDisplayList.cpp:294
#20 0x17f4ff42 in nsLayoutUtils::PaintFrame (aRenderingContext=0x3c260b20, aFrame=0x25694ac, aDirtyRegion=@0xbfffc07c, aBackground=4294967295) at /Users/roc/mozilla-trunk/layout/base/nsLayoutUtils.cpp:872
#21 0x17f5d583 in PresShell::Paint (this=0x25c2800, aView=0x3bc60c00, aRenderingContext=0x3c260b20, aDirtyRegion=@0xbfffc07c) at /Users/roc/mozilla-trunk/layout/base/nsPresShell.cpp:5320
#22 0x18345cbf in nsViewManager::RenderViews (this=0x3c228700, aView=0x3c248000, aRC=@0x3c260b20, aRegion=@0xbfffc154) at /Users/roc/mozilla-trunk/view/src/nsViewManager.cpp:602
#23 0x18349f2f in nsViewManager::Refresh (this=0x3c228700, aView=0x3c248000, aContext=0x3c260b20, aRegion=0x3bc2f470, aUpdateFlags=1) at /Users/roc/mozilla-trunk/view/src/nsViewManager.cpp:491
#24 0x1834a730 in nsViewManager::DispatchEvent (this=0x3c228700, aEvent=0xbfffc454, aStatus=0xbfffc358) at /Users/roc/mozilla-trunk/view/src/nsViewManager.cpp:1065
#25 0x18341b81 in HandleEvent (aEvent=0xbfffc454) at /Users/roc/mozilla-trunk/view/src/nsView.cpp:168
#26 0x1533bcb6 in nsChildView::DispatchEvent (this=0x3bc6f0f0, event=0xbfffc454, aStatus=@0xbfffc3cc) at /Users/roc/mozilla-trunk/widget/src/cocoa/nsChildView.mm:1418
#27 0x15336872 in nsChildView::DispatchWindowEvent (this=0x3bc6f0f0, event=@0xbfffc454) at /Users/roc/mozilla-trunk/widget/src/cocoa/nsChildView.mm:1431
#28 0x1533eda9 in -[ChildView drawRect:] (self=0x3bc6f190, _cmd=0x90aa7bac, aRect={origin = {x = 0, y = 0}, size = {width = 1036, height = 300}}) at /Users/roc/mozilla-trunk/widget/src/cocoa/nsChildView.mm:2310
#29 0x933153d1 in -[NSView _drawRect:clip:] ()


Hmm, actually this could be the one:

#0  0x92e6c796 in HIScrollBar::DrawSelf ()
#1  0x92e1c027 in HIView::DrawCacheOrSelf ()
#2  0x92e1be27 in HIView::SendDraw ()
#3  0x92ed8417 in HIView::RecursiveDrawNonComposited ()
#4  0x92ed7bde in HIView::DrawNonComposited ()
#5  0x92e1ba20 in HIView::Draw ()
#6  0x92e43d2e in HIView::ValueFieldChangedSelf ()
#7  0x92e136e7 in HIView::EventHandler ()
#8  0x92def4d7 in DispatchEventToHandlers ()
#9  0x92deeb7c in SendEventToEventTargetInternal ()
#10 0x92deea41 in SendEventToEventTargetWithOptions ()
#11 0x92e43c9c in SendControlDefValueFieldChanged ()
#12 0x92e43bad in HIView::DoControlValueUpdate ()
#13 0x3bd9e552 in CXDoc::SetScrollBar ()
#14 0x3bd9e6e9 in CXDoc::DrawDoc ()
#15 0x3bdaeffe in CXHTML::AssignWnd ()
#16 0x3be02e2a in CBelusXEditorCtrl::SetWindow ()
#17 0x3bd6919b in CPlugin::SetWindow ()
#18 0x3bd6a1d8 in NPP_SetWindow ()
#19 0x3a3492df in ns4xPluginInstance::SetWindow (this=0x3baefaf0, window=0x2950df4) at /Users/roc/mozilla-trunk/modules/plugin/base/src/ns4xPluginInstance.cpp:1153
#20 0x17fe6eee in nsPluginInstanceOwner::FixUpPluginWindow (this=0x3baa8750, inPaintState=2) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:4126
#21 0x17fe7754 in nsObjectFrame::CallSetWindow (this=0x238cdd0) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:859
#22 0x17fe8995 in nsObjectFrame::Instantiate (this=0x238cdd0, aMimeType=0x3bce1728 "application/x-xstandard", aURI=0x3a065fb0) at /Users/roc/mozilla-trunk/layout/generic/nsObjectFrame.cpp:1456

maybe the plugin shouldn't be drawing itself during SetWindow?
Or maybe neither of those is the one ... it seems both the good and bad scrollbars are being drawn between breakpoints in HIScrollBar::DrawSelf, so there must be some other scrollbar drawing API that's being entered :-(.
Is is possible that incorrect screen coordinates are being sent to the plug-in and therefore it draws the scroll bars in the wrong place?
It's only drawing scrollbars in the wrong place, no other content, so that's probably not it.

It actually might not be the plugin drawing the scrollbars. I can't tell where the drawing is coming from :-(.
If you comment out the scrollbar drawing code in the mac native theme and the scrollbar is still drawing, chances are it is the plugin doing it.
Okay, the bogus scrollbars are being drawn some time between the instantiation of the plugin (nsObjectFrame::Instantiate) and the first call to HIThemeDrawTrack after that. [NSScroller drawRect:] is not being called at any time, so I have no idea how these scrollbars are being drawn.

Vlad, I'm concerned about drawing going on inside SetWindow. Could you try disabling that in your plugin somehow and see if that makes the problem go away?
I checked the CPlugin::SetWindow() and there is a comment that reads "DO NOT draw or paint during SetWindow, do it on next update Event". So I am pretty sure we don't do any painting in the SetWindow event but I will double check with the developer responsible for this code next week.

>[NSScroller drawRect:] is not being called at any time...
If I am not mistaken, NSScroller is part of the Cocoa framework? Our plugin uses Carbon.

Robert, what has changed in this build that might affect the plug-in API?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/04/2007-04-11-04-trunk/

I don't know. It's possible that removing the native scrollbar widgets changed the ordering of native events or something subtle like that.

See comment #12; you definitely *are* painting during SetWindow, where CXDoc::SetScrollBar is calling HIView::DoControlValueUpdate.
Thanks for pointing that out. During what event should painting begin?
Ideally you would only paint when we send you a paint event. The stack in comment #11, for example.
We've fixed the issue on our side. Bryan, Boris and Robert - thank you very much for helping to diagnose the problem. Please consider this bug closed.
Cool, you're welcome. I'll mark this INVALID since it wasn't a bug in Gecko.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.