Bug 27272 – [Leopard] Fixed position elements flash when CSS transforms are applied on page > 2048px tall

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[M. Dave Auayan]

Fixed position elements flash when a CSS transform is applied to an element on a long page in the latest WebKit nightly builds

[M. Dave Auayan]

Created attachment 32730 [details]
Example

[M. Dave Auayan]

Also, I just noticed the transition is not working.

[Simon Fraser (smfr)]

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 ***

[M. Dave Auayan]

(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.

[Simon Fraser (smfr)]

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 ***

[M. Dave Auayan]

(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?

[M. Dave Auayan]

Created attachment 32753 [details]
Video of behaviour

[Simon Fraser (smfr)]

Does this same problem happen if you make a new user account and then try the testcase? Can you try a different Mac too?

[M. Dave Auayan]

(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.

[Simon Fraser (smfr)]

Reopening based on last comment.

[Simon Fraser (smfr)]

Dave: could you email me a System Profile for your machine please?

[Simon Fraser (smfr)]

Hardware is Intel, 10.5.7

[Simon Fraser (smfr)]

Ah, this is related to the page height. I see the problem. It's Leopard-only.

[Simon Fraser (smfr)]

<rdar://problem/7067867>

[Simon Fraser (smfr)]

Created attachment 34349 [details]
Patch

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

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/46947

[Simon Fraser (smfr)]

*** Bug 28705 has been marked as a duplicate of this bug. ***

[Simone Manganelli]

I am seeing this bug in r47686.  Are you sure this is fixed?

[M. Dave Auayan]

(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.

[Simone Manganelli]

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.

[Simon Fraser (smfr)]

(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.

[Simone Manganelli]

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.

[Simone Manganelli]

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.

[Simon Fraser (smfr)]

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!

[M. Dave Auayan]

(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

[Simon Fraser (smfr)]

(In reply to comment #26)
> I've got 8192

What is the hardware?

[M. Dave Auayan]

(In reply to comment #27)
> (In reply to comment #26)
> > I've got 8192
> 
> What is the hardware?

NVIDIA GeForce 8600M GT

[Simone Manganelli]

MAX_TEXTURE_SIZE = 2048, with a Intel GMA 950 "graphics" "card".

[Simon Fraser (smfr)]

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?

[M. Dave Auayan]

(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.

[Simon Fraser (smfr)]

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?

[M. Dave Auayan]

(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.

[Simon Fraser (smfr)]

(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.

[Eric Seidel (no email)]

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!

[Simone Manganelli]

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.

[Simon Fraser (smfr)]

Not fixed. The fix needs changing from 4k px to 2k px.

[Simon Fraser (smfr)]

Created attachment 39611 [details]
Patch

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/48401