Visit the page in the url, clicking into or out of the docstock element causes it to move by one pixel. I've see this in other flash and silverlight objects though it was not cleanly reproducible. I see this in today's 1.9.1 build and is not reproducible in Fx3.

Works correctly on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090129 Minefield/3.2a1pre Broken on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090130 Minefield/3.2a1pre Changesets involved http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e95fb8b811ac&tochange=76540a65adc0

I suspect this was bug 478267, fixed in 1.9.1 a few days ago (regression from changeset 2676947cb41c). Can you update to a trunk nightly or 1.9.1 nightly and see if the bug still occurs? Marking minus on the assumption it was that bug.

Still happens in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre Another example is any video at Academic Earth http://academicearth.org/lectures/measurements-space-and-time

Roc, did you mean to minus this per comment 3?

No, I was assuming this would be fixed by 478267, but it wasn't.

OK, so what happens here is that when we focus the plugin, we give it an outline. That means the nsObjectFrame gets an overflow area 1px wide around the plugin. We set its view mDimBounds to that overflow area. That's the area that the view's widget is given. The plugin is attached to that widget, so it appears at the top-left of the overflow area. The simplest way to fix this, although it's not very simple, is to give the view an anonymous inner view which is where we attach the actual widget, like we do for nsSubdocumentFrames. That inner view would be set to the element's content-rect. This could make borders and padding work on the plugin too.

I should be able to write a simple testcase for this using the window-mode plugin support I just developed for the test plugin on X :-).

I think we should just back out bug 478267 to fix this on branch. The work in comment #7 isn't justified by bug 478267. I'll leave this open on trunk; it should be fixed by my plugin hoisting work.

Taking off the blocker list since I backed out the fix for bug 478267; this bug should no longer be present on branch.

Verified that this does not appear on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4pre) Gecko/20090411 Shiretoko/3.5b4pre. As roc said in comment 10 still an issue for the trunk.

The bug is still there for Minefield/3.6a1pre

Fixed by checkin for bug 508495 if not before. The tests in bug 508495 cover this.