| Summary: | [Leopard] Fixed position elements flash when CSS transforms are applied on page > 2048px tall | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | M. Dave Auayan <m> | ||||||||||
| Component: | CSS | Assignee: | Simon Fraser (smfr) <simon.fraser> | ||||||||||
| Status: | RESOLVED FIXED | ||||||||||||
| Severity: | Normal | CC: | eric, simon.fraser, simX_other | ||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||||
| Hardware: | Mac (Intel) | ||||||||||||
| OS: | OS X 10.5 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
M. Dave Auayan
2009-07-14 12:57:19 PDT
Created attachment 32730 [details]
Example
Also, I just noticed the transition is not working. 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 *** (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. 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 *** (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? Created attachment 32753 [details]
Video of behaviour
Does this same problem happen if you make a new user account and then try the testcase? Can you try a different Mac too? (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. Reopening based on last comment. Dave: could you email me a System Profile for your machine please? Hardware is Intel, 10.5.7 Ah, this is related to the page height. I see the problem. It's Leopard-only. 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 *** Bug 28705 has been marked as a duplicate of this bug. *** I am seeing this bug in r47686. Are you sure this is fixed? (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. 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. (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. 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. 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. 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! (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 (In reply to comment #26) > I've got 8192 What is the hardware? (In reply to comment #27) > (In reply to comment #26) > > I've got 8192 > > What is the hardware? NVIDIA GeForce 8600M GT MAX_TEXTURE_SIZE = 2048, with a Intel GMA 950 "graphics" "card". 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? (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. 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? (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. (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. 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! 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. Not fixed. The fix needs changing from 4k px to 2k px. Created attachment 39611 [details]
Patch
|