docstoc element on the page moves 1px when clicked

VERIFIED FIXED

Status

()

P2
normal
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: kbrosnan, Assigned: roc)

Tracking

({regression})

Trunk
x86
Windows Vista
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
Flags: blocking1.9.1?
(Reporter)

Comment 1

10 years ago
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
(Reporter)

Comment 2

10 years ago
Created attachment 363519 [details]
minimal testcase
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.
Depends on: 478267
Flags: blocking1.9.1? → blocking1.9.1-
(Reporter)

Comment 4

10 years ago
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
Flags: blocking1.9.1- → blocking1.9.1+
Priority: -- → P2
Assignee: nobody → roc
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.
Flags: blocking1.9.1+
Version: 1.9.1 Branch → Trunk
(Reporter)

Comment 11

10 years ago
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.

Comment 12

9 years ago
The bug is still there for Minefield/3.6a1pre
Depends on: 486473
Fixed by checkin for bug 508495 if not before. The tests in bug 508495 cover this.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
status1.9.2: --- → beta1-fixed
Flags: in-testsuite+
Resolution: --- → FIXED
(Reporter)

Updated

9 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.