Bug 27272 - [Leopard] Fixed position elements flash when CSS transforms are applied on page > 2048px tall
Summary: [Leopard] Fixed position elements flash when CSS transforms are applied on pa...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.5
: P2 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
: 28705 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-07-14 12:57 PDT by M. Dave Auayan
Modified: 2009-09-15 14:27 PDT (History)
3 users (show)

See Also:


Attachments
Example (881 bytes, text/html)
2009-07-14 12:58 PDT, M. Dave Auayan
no flags Details
Video of behaviour (232.84 KB, video/quicktime)
2009-07-14 17:38 PDT, M. Dave Auayan
no flags Details
Patch (6.98 KB, patch)
2009-08-07 17:57 PDT, Simon Fraser (smfr)
mitz: review+
Details | Formatted Diff | Diff
Patch (1.63 KB, patch)
2009-09-15 13:14 PDT, 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 M. Dave Auayan 2009-07-14 12:57:19 PDT
Fixed position elements flash when a CSS transform is applied to an element on a long page in the latest WebKit nightly builds
Comment 1 M. Dave Auayan 2009-07-14 12:58:35 PDT
Created attachment 32730 [details]
Example
Comment 2 M. Dave Auayan 2009-07-14 13:02:49 PDT
Also, I just noticed the transition is not working.
Comment 3 Simon Fraser (smfr) 2009-07-14 15:12:54 PDT
The flash is really just the text appearance changing, right? If so, I think this is a dup.

If the transitions are broken, please file another bug. They work for me.

*** This bug has been marked as a duplicate of bug 23364 ***
Comment 4 M. Dave Auayan 2009-07-14 15:44:14 PDT
(In reply to comment #3)
> The flash is really just the text appearance changing, right? If so, I think
> this is a dup.
> 

The flashing element (a div with a fixed position, in the example) is not the element being transformed. The fixed positioned element disappears from the page, and reappears at the end of the transform when an element on the page has a transform applied (in the example's case, on :hover). 

If the example wasn't obvious, then perhaps my original issue has been resolved.

> If the transitions are broken, please file another bug. They work for me.
>

I'm currently updating, my working copy, once it's done building, i'll revisit this.
Comment 5 Simon Fraser (smfr) 2009-07-14 15:46:55 PDT
Ah, then I think this a dup of bug 26430. It works fine for me in a recent nightly.

*** This bug has been marked as a duplicate of bug 26430 ***
Comment 6 M. Dave Auayan 2009-07-14 17:36:06 PDT
(In reply to comment #5)
> Ah, then I think this a dup of bug 26430. It works fine for me in a recent
> nightly.
> 

I haven't finished building yet, but so far, I've tried this on my macbook pro and mac mini with the same results (flashing) in the latest nightly. The testcase for bug 26430 appears to be fixed. The flashing started recently, the r45754 build, perhaps.

The current version of Safari and the Nightly build for Windows do not exhibit this behaviour. I see the platform was incorrectly (automatically) set as PC, maybe this is the source of the confusion?
Comment 7 M. Dave Auayan 2009-07-14 17:38:24 PDT
Created attachment 32753 [details]
Video of behaviour
Comment 8 Simon Fraser (smfr) 2009-07-14 17:42:52 PDT
Does this same problem happen if you make a new user account and then try the testcase? Can you try a different Mac too?
Comment 9 M. Dave Auayan 2009-07-15 10:13:40 PDT
(In reply to comment #8)
> Does this same problem happen if you make a new user account and then try the
> testcase? Can you try a different Mac too?

Indeed, this problem persists across a MacBook Pro, a MacBook, a Mac Mini, and a Titanium PowerBook, all running the current version of Leopard (not Snow Leopard).

The nightly builds before 45754 do not have this problem.
Comment 10 Simon Fraser (smfr) 2009-07-15 10:24:23 PDT
Reopening based on last comment.
Comment 11 Simon Fraser (smfr) 2009-07-15 10:26:40 PDT
Dave: could you email me a System Profile for your machine please?
Comment 12 Simon Fraser (smfr) 2009-07-15 10:49:07 PDT
Hardware is Intel, 10.5.7
Comment 13 Simon Fraser (smfr) 2009-07-16 18:03:06 PDT
Ah, this is related to the page height. I see the problem. It's Leopard-only.
Comment 14 Simon Fraser (smfr) 2009-07-16 18:28:12 PDT
<rdar://problem/7067867>
Comment 15 Simon Fraser (smfr) 2009-08-07 17:57:05 PDT
Created attachment 34349 [details]
Patch
Comment 16 mitz 2009-08-07 19:04:11 PDT
Comment on attachment 34349 [details]
Patch

> +        WebHTMLView* htmlView = (WebHTMLView*)documentView;

With Objective-C objects, the star should go next to the variable name. There should also be a space before the star in the cast.

> +#if defined(BUILDING_ON_LEOPARD)
> +    // Turn off default animations.
> +    NSNull* nullValue = [NSNull null];

The star should be next to nullValue.

> +    NSDictionary* actions = [NSDictionary dictionaryWithObjectsAndKeys:
> +                             nullValue, @"anchorPoint",
> +                             nullValue, @"bounds",
> +                             nullValue, @"contents",
> +                             nullValue, @"contentsRect",
> +                             nullValue, @"opacity",
> +                             nullValue, @"position",
> +                             nullValue, @"shadowColor",
> +                             nullValue, @"sublayerTransform",
> +                             nullValue, @"sublayers",
> +                             nullValue, @"transform",
> +                             nullValue, @"zPosition",
> +                             nil];
> +    [viewLayer setStyle:[NSDictionary dictionaryWithObject:actions forKey:@"actions"]];

We usually avoid autoreleased objects like the above NSNull and two NSDictionaries. It doesn’t really matter that they are autoreleased in this case.

> +    const float kMaxHeight = 4096;

Please use CGFloat. I don’t think the k prefix is necessary.

> +        float documentHeight = layerViewFrame.size.height;

Please use CGFloat.

> +        float topOffset = NSMinY(visibleRect);

Ditto.

> +        float bottomOffset = documentHeight - layerViewFrame.size.height - topOffset;

…

r=me
Comment 17 Simon Fraser (smfr) 2009-08-07 21:08:56 PDT
http://trac.webkit.org/changeset/46947
Comment 18 Simon Fraser (smfr) 2009-08-25 08:45:39 PDT
*** Bug 28705 has been marked as a duplicate of this bug. ***
Comment 19 Simone Manganelli 2009-08-25 10:05:43 PDT
I am seeing this bug in r47686.  Are you sure this is fixed?
Comment 20 M. Dave Auayan 2009-08-25 10:08:20 PDT
(In reply to comment #19)
> I am seeing this bug in r47686.  Are you sure this is fixed?

The bug displayed in my test case seems to be fixed, however I'm still getting very similar behavior on my site at http://lib.rario.us/ - i haven't had a chance to reduce that yet.
Comment 21 Simone Manganelli 2009-08-25 10:11:17 PDT
The test case in this bug report flashes just as described; i.e.: it's not fixed for me at all.  The video of the behavior shows exactly what I'm seeing in r47686.

Also see bug 28705 ( https://bugs.webkit.org/show_bug.cgi?id=28705 ) for another reduction that isn't fixed in r47686.
Comment 22 Simon Fraser (smfr) 2009-08-25 10:20:19 PDT
(In reply to comment #20)
> The bug displayed in my test case seems to be fixed, however I'm still getting
> very similar behavior on my site at http://lib.rario.us/

Please give a full URL that I can access without having to create an account or log in.

(In reply to comment #21)
> The test case in this bug report flashes just as described; i.e.: it's not
> fixed for me at all.  The video of the behavior shows exactly what I'm seeing
> in r47686.
> 
> Also see bug 28705 ( https://bugs.webkit.org/show_bug.cgi?id=28705 ) for
> another reduction that isn't fixed in r47686.

I can reproduce neither of these issues with a current nightly build.

Please make sure you are actually running the nightly, and that you don't have any DYLD_FRAMEWORK_PATH stuff set up that might cause it to pick up the wrong frameworks.
Comment 23 Simone Manganelli 2009-08-25 10:27:24 PDT
Yep, running the nightly.  No DYLD_FRAMEWORK_PATH set up.  Tested this under a completely new user account, both bugs still happen.  Mac OS X 10.5.8, 2 GHz Intel Core 2 Duo MacBook.
Comment 24 Simone Manganelli 2009-08-25 10:32:32 PDT
I went back to r46969, too, the earliest nightly I can download that supposedly has the fix, and the problem still happens there too.  So maybe there's another case that causes the bug to happen that was never fixed in the first place.
Comment 25 Simon Fraser (smfr) 2009-08-25 10:41:30 PDT
Simone, M.Dave:
please give me the following information for your system:
Run OpenGL Driver Monitor (in /Developer/Applications/Graphics Tools/) -- you'll need Developer tools installed.
Choose Monitors -> Renderer Info
Expand the line that refers to your graphics hardware
Expand the line "OpenGL limits"
Expand the line "Textures"
Now look at the number for MAX_TEXTURE_SIZE and report back here.

Thanks!
Comment 26 M. Dave Auayan 2009-08-25 10:43:38 PDT
(In reply to comment #25)
> Simone, M.Dave:

> Now look at the number for MAX_TEXTURE_SIZE and report back here.
> 
> Thanks!

I've got 8192
Comment 27 Simon Fraser (smfr) 2009-08-25 10:44:58 PDT
(In reply to comment #26)
> I've got 8192

What is the hardware?
Comment 28 M. Dave Auayan 2009-08-25 10:47:15 PDT
(In reply to comment #27)
> (In reply to comment #26)
> > I've got 8192
> 
> What is the hardware?

NVIDIA GeForce 8600M GT
Comment 29 Simone Manganelli 2009-08-25 10:51:50 PDT
MAX_TEXTURE_SIZE = 2048, with a Intel GMA 950 "graphics" "card".
Comment 30 Simon Fraser (smfr) 2009-08-25 10:53:42 PDT
Simone: I believe you are seeing the bug (the fix was for 4k texture sizes).
M. Dave: I think your nightly is not running with the right frameworks. Do you have a ~/.MacOSX/environment.plist set up with a DYLD_FRAMEWORK_PATH in it?
Comment 31 M. Dave Auayan 2009-08-25 11:12:02 PDT
(In reply to comment #30)
> M. Dave: I think your nightly is not running with the right frameworks. Do you
> have a ~/.MacOSX/environment.plist set up with a DYLD_FRAMEWORK_PATH in it?

The only thing I have there is the PATH entry.

WebKit nightly on a new user account also exhibits the same behavior on my site.
Comment 32 Simon Fraser (smfr) 2009-08-25 11:17:20 PDT
M. Dave: ah, MAX_3D_TEXTURE_SIZE on your hardware is 2k, so maybe the bug still applies. If you experiment with a testcase, does the bug start to show when the page gets > 2048px tall?
Comment 33 M. Dave Auayan 2009-08-25 12:04:29 PDT
(In reply to comment #32)
> M. Dave: ah, MAX_3D_TEXTURE_SIZE on your hardware is 2k, so maybe the bug still
> applies. If you experiment with a testcase, does the bug start to show when the
> page gets > 2048px tall?

The page in the original test case should be 10,000px tall and I have no issues in webkit. In case I misunderstood, I also managed to get a 2600px tall window and still had no problem.

This page at http://lib.rario.us/ is a very short page, but also exhibits flashing when you hover over the logo on the top left.

I will try to reduce this and attach a new test case.
Comment 34 Simon Fraser (smfr) 2009-08-25 12:07:48 PDT
(In reply to comment #33)
> (In reply to comment #32)
> > M. Dave: ah, MAX_3D_TEXTURE_SIZE on your hardware is 2k, so maybe the bug still
> > applies. If you experiment with a testcase, does the bug start to show when the
> > page gets > 2048px tall?
> 
> The page in the original test case should be 10,000px tall and I have no issues
> in webkit. In case I misunderstood, I also managed to get a 2600px tall window
> and still had no problem.

OK, so I was confused. This all makes sense now.

> This page at http://lib.rario.us/ is a very short page, but also exhibits
> flashing when you hover over the logo on the top left.
> 
> I will try to reduce this and attach a new test case.

That's expected behavior at present (see 23364). No need for a testcase or another bug.
Comment 35 Eric Seidel (no email) 2009-09-01 03:11:32 PDT
As far as I can tell from Simon's comments above this particular bug can be marked fixed and further discussion is under bug 23364.  Thanks!
Comment 36 Simone Manganelli 2009-09-01 03:16:29 PDT
Eric: no, this bug is not fixed, I'm still experiencing it and Simon acknowledged that.  Bug 23364 is for an unrelated bug that M. Dave mentioned that he thought was the same as this bug.
Comment 37 Simon Fraser (smfr) 2009-09-01 08:20:32 PDT
Not fixed. The fix needs changing from 4k px to 2k px.
Comment 38 Simon Fraser (smfr) 2009-09-15 13:14:22 PDT
Created attachment 39611 [details]
Patch
Comment 39 Simon Fraser (smfr) 2009-09-15 14:27:03 PDT
http://trac.webkit.org/changeset/48401