Bug 33821 - REGRESSION (r53110): Find My iPhone message dialog is offset from original position once it gets focus
Summary: REGRESSION (r53110): Find My iPhone message dialog is offset from original po...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2010-01-18 18:05 PST by Adele Peterson
Modified: 2010-01-22 17:18 PST (History)
2 users (show)

See Also:


Attachments
Reduced testcase (896 bytes, text/html)
2010-01-22 10:34 PST, Simon Fraser (smfr)
no flags Details
Patch (28.31 KB, patch)
2010-01-22 15:05 PST, Simon Fraser (smfr)
mitz: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adele Peterson 2010-01-18 18:05:18 PST
Steps to reproduce:

1) You must have Find My iPhone enabled with a MobileMe account.
2) Go to me.com, click on Account Settings, and select "Find my iPhone"
3) Click on the button to display a message on your iPhone
4) Click in the textarea

Observe that the dialog and overlay end up significantly offset from the original position

<rdar://problem/7549496>
Comment 1 Adele Peterson 2010-01-18 18:06:37 PST
This was caused by http://trac.webkit.org/changeset/53109
Comment 2 Darin Adler 2010-01-18 21:14:36 PST
First thing I would try is to revert that patch and set m_loadManually to NP_FULL in the constructor and see what that does.
Comment 3 Darin Adler 2010-01-19 07:52:21 PST
Second thing I would try is to revert the patch and set m_loadManually to NP_EMBED in the constructor and see what that does.
Comment 4 Adele Peterson 2010-01-19 09:53:11 PST
I'm running into an unrelated assertion on this page in debug WebKit.  So I'll try commenting out the assert to try your suggestions.
Comment 5 Adele Peterson 2010-01-19 10:48:21 PST
My regression testing was off by one.  This was actually caused by r53110
Comment 6 Simon Fraser (smfr) 2010-01-19 11:45:08 PST
Yeah, that's me.
Comment 7 Simon Fraser (smfr) 2010-01-22 10:34:40 PST
Created attachment 47211 [details]
Reduced testcase
Comment 8 Simon Fraser (smfr) 2010-01-22 11:07:42 PST
Filed bug 34009 on avoiding compositing mode just for a 0x0 plugin.
Comment 9 Simon Fraser (smfr) 2010-01-22 11:33:08 PST
The issue here is that there's a fixed position div inside an abs. position div, and the fixed position div is using the wrong offsets.

In general, there's a conflict between the geometry and layering hierarchies for fixed position elements. In terms of geometry, a fixed layer would naturally be anchored at the root, but in terms of layering it should be anchored in its container.

Layering comes first, but we'll have to throw animations of things with fixed descendants into software.
Comment 10 Simon Fraser (smfr) 2010-01-22 15:05:04 PST
Created attachment 47230 [details]
Patch
Comment 11 Simon Fraser (smfr) 2010-01-22 15:06:13 PST
Filed bug 34012 on animating fixed position containers.
Comment 12 mitz 2010-01-22 17:00:22 PST
Comment on attachment 47230 [details]
Patch

> +        RenderLayer* currLayer = parent();
> +        while (currLayer) {
> +            if (currLayer == ancestorLayer)
> +                foundAncestor = true;
> +
> +            if (isFixedPositionedContainer(currLayer)) {
> +                fixedPositionContainerLayer = currLayer;
> +                ASSERT(foundAncestor);
> +                break;
> +            }
> +            
> +            currLayer = currLayer->parent();
> +        }

Can be written as a for loop with currLayer in the scope of the loop.
Comment 13 Simon Fraser (smfr) 2010-01-22 17:18:05 PST
http://trac.webkit.org/changeset/53742