421026 - Viewpoint plugin content renders in wrong portion of the viewport

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Viewpoint Media Player, defect, P2)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

(I suspect this might end up in Cocoa land, but filing for now in Plug-Ins, since it's also possible that it's a bug in the plugin itself.)

Summary: Viewpoint plugin content renders in wrong portion of the viewport

Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4) Gecko/2008030317 Firefox/3.0b4

^^^ Happens with trunk too...

URL: http://www.viewpoint.com/technologies/viewpoint-media-player-hyperview.shtml

Steps to Reproduce:

1. Download [http://www.viewpoint.com/installer/index.html?05.00.02.29|frame&http://www.viewpoint.com/technologies/viewpoint-media-player.shtml] the Viewpoint plugin for Mac OS X (I'm on 10.5)
2. Install it
3. Restart
4. Load, for example, http://www.viewpoint.com/technologies/viewpoint-media-player-hyperview.shtml

Expected Results:

Content renders in the right area

Actual Results:

Content renders in the upper left-hand of the viewport

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Requesting blocking until we figure out if this is either us or the plugin itself.

Comment 2

[Tony Chung [:tchung]]

Is this a regression?   If so, should we nominate this as a relnote for beta 4 mac users?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Stephen, I'm not able to download the media plugin. Minefield and even Safari don't react when clicking the download button. Do you have a direct link to the download?

Comment 4

[Matthew Gregan [:kinetik]]

I can reproduce this with nightly builds.  A debug build of trunk is even worse, it crashes inside the plugin the first(?) time we try to paint.  It looks like this is fallout from enabling Cocoa widgets, because the 2006-09-28-08 nightly works (as does Firefox 2) and the 2006-09-29-06 nightly fails as described.

That makes this a duplicate of bug #419205, but either this bug or that one needs to be (re)considered for blocking1.9.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Windows crashes too; see bug 421030.

Comment 6

[Johnny Stenback (:jst)]

why does it matter that we bypass checkloaduri? Seems like chrome should be able to load anything if it so desires.

Bypassing the data document content policy does seem wrong though. Do we in general not apply content policies to chrome stuff as a perf optimization? I seem to recall something to that effect.

Seems wrong to not give chrome XHR documents the system principal. Not doing that could be a fix, but it does seems like a hack to me.

If the worse thing that'll happen is that we bypass the data document content policy this doesn't seem like a blocker. -- jonas.

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

Say what?  Wrong bug comment?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)

Looks like this was meant for bug 421228.

Comment 9

[Johnny Stenback (:jst)]

Yup, it was. Thanks.

Comment 10

[Johnny Stenback (:jst)]

Sounds bad, Josh, care to have a look?

Comment 11

[Johnny Stenback (:jst)]

The URL in this bug is a 404. Anyone have an updated testcase? Given how rare this plugin appears to be we're not going to hold the release for this one.

Comment 12

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #11)
> The URL in this bug is a 404. Anyone have an updated testcase? Given how rare
> this plugin appears to be we're not going to hold the release for this one.

http://www.viewpoint.com/installer/index.html?05.00.02.29|frame&http://salesdemo.viewpoint.com/vla/asset/demo/29_021951/index.html should work?

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Also, loading http://www.lexus.com/models/GSh/ and clicking "Photo Gallery", followed by "Virtual Tour", also shows bad viewport-rendering issues, but is cross-platform; might be a separate bug.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #13)
> Also, loading http://www.lexus.com/models/GSh/ and clicking "Photo Gallery",
> followed by "Virtual Tour", also shows bad viewport-rendering issues, but is
> cross-platform; might be a separate bug.

Thats not a plugin issue. The page you are referring to uses normal DHTML for presentation. But thanks anyway for the URL which crashed my Firefox. Filed that as bug 424609.

Comment 15

[Matthew Gregan [:kinetik]]

With a current debug build, I still crash the first time we paint the plugin after it becomes visible.  The top of the stack is:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x01970000
0x947a2fdf in BBFastDoubleSrcCopy ()
(gdb) bt
#0  0x947a2fdf in BBFastDoubleSrcCopy ()
#1  0x9479ad1c in Stretch ()
#2  0x94799968 in CommonBits ()
#3  0x947a8727 in CopyBits ()
#4  0x16f6fc62 in MTSGetCreatorFunction ()
#5  0x16f5dc5e in MTSGetCreatorFunction ()
#6  0x16be2a8b in dyld_stub_printf ()
#7  0x16be86a5 in dyld_stub_printf ()
#8  0x16be881f in dyld_stub_printf ()
#9  0x16c24252 in MTSGetCreatorFunction ()
#10 0x16c23427 in MTSGetCreatorFunction ()
#11 0x16be0463 in dyld_stub_printf ()
#12 0x16b342f9 in main ()
#13 0x16b343c2 in main ()
#14 0x16b34937 in main ()
#15 0x16b3301d in dyld_stub_strlen ()
#16 0x1d595b6c in ns4xPluginInstance::HandleEvent (this=0x1642d5d0, event=0xbfffc360, handled=0xbfffc35c) at /Users/kinetik/work/mozilla-cvs/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:1303

Note that the address the EXC_BAD_ACCESS occurred at happens to be the address of the memory "backing" the graphics port we passed to the plugin:

NPP SetWindow called: this=0x1731a0e0, [x=1,y=1,w=2,h=2], win[0x1731be50, -1, -89] clip[t=89,b=89,l=1,r=1], return=0

gdb) call (void*)FrontWindow()
$6 = (void *) 0x1731b010
(gdb) call (void*)GetWindowPort(0x1731b010)
$7 = (void *) 0x1731be50
(gdb) call (int)QDDebugPrintPortInfo(0x1731be50)
Dumping port 0x1731BE50...
    PixMap:              0x5D1718
        Base Address:    0x1970000 [onscreen, buffered]
        RowBytes:        0xFFFFA000
        Bounds:          (-118, -8, 808, 907)  (915w x 926h)
        Depth:           0020
    Port bounds:         (-96, -8, 830, 907)  (915w x 926h)
    Port shape:          0x5D1784 (-96, -8, 808, 907)  (915w x 904h) [rect]
    Vis rgn:             0x5D171C (0, 0, 304, 440)  (440w x 304h) [rect]
    Clip rgn:            0x5D1724 (96, 8, 400, 448)  (440w x 304h) [rect]

When we crash, the current port is not the port we passed to the plugin:

gdb) call (void*)GetThreadPort()
$1 = (void *) 0x1c693c10
(gdb) call (int)QDDebugPrintPortInfo(0x1c693c10)
Dumping port 0x1C693C10...
    PixMap:              0x5D12BC
        Base Address:    0x1970000 [onscreen]
        RowBytes:        0xFFFFA000
        Bounds:          (0, 0, 0, 0)  (0w x 0h)
        Depth:           0020
    Port bounds:         (0, 0, 1200, 1920)  (1920w x 1200h)
    Port shape:          0x5D1328 (0, 0, 1200, 1920)  (1920w x 1200h) [rect]
    Vis rgn:             0x5D12C0 (0, 0, 1200, 1920)  (1920w x 1200h) [rect]
    Clip rgn:            0x5D12C8 (-32767, -32767, 32767, 32767)  (65534w x 65534h) [rect]

(this looks like the fallback port set by a call to SetPort(NULL) or possibly some other way)

This probably explains why the plugin is drawing to the wrong place--the current port at the time CopyBits is called by the plugin (when copying graphics data to the on-screen graphics port) is not the same port as the destination port.  As far as I understand, when the destination graphics port for CopyBits is an on-screen graphics port, it must also be set as the current port.

Indeed, changing nsChildView::StartDrawPlugin to leave the current port set to the plugin port avoids the crash (and the plugin paints in the correct location), but only the bottom quarter of the plugin content is painted, the rest is black.

If the plugin assumes that the current port is the right one for it to use, and we are not setting the plugin port to the current port before calling the plugin to paint, that may explain the problem.  The existing code in nsChildView::StartDrawPlugin sets the plugin port up but then may reset the current port to the port in use before StartDrawPlugin was called (if they differed).

Comment 16

[Matthew Gregan [:kinetik]]

Forgot to mention: I also crash with an optimized build (but still built with --enable-debug), but the nightlies do not crash for me.  The plugin content paints in the wrong location, but there is no crash.

Comment 17

[Matthew Gregan [:kinetik]]

If I call LockPortBits in nsChildView::StartDrawPlugin and UnlockPortBits in nsChildView::EndDrawPlugin (with no other changes--the hack mentioned earlier to leave the current port set to the plugin port has been removed), the plugin does not crash and paints in the correct location.  However, I'm fairly sure that it should not be the plugin host's responsibility to lock/unlock the port bits, so I'm not proposing this as a fix, just using it to aid debugging.

Even with this change in place, there is a further problem, which is that click-dragging inside the plugin area (to move the car/camera) causes the invalidated area of the plugin to paint black until I release the mouse button.  With Firefox 2, this also worked as expected.

Comment 18

[Damian Frank]

I work on a cross-platform plugin that also has this problem.  We (unfortunately) have to use QuickDraw to use CopyBits.  We don't have a crash, but we do render on the wrong part of the screen.  I can sort of work around this by using SetPort to set the port to the one we were given by NPP_SetWindow, but then the clipping area is still incorrect.  The top inch or so of the page content area is clipped out.

Can I safely assume that this is not our bug and will be fixed in Firefox?  (Our plugin works fine with 2.x, of course.)  Thanks.

Comment 19

[Damian Frank]

Actually, I think our bug is probably better described in bug 421026, so please disregard my comment.