Bug 15164

Summary: FOUC at orange.co.il
Product: WebKit Reporter: mitz
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: ahmad.saleem792, ap, bfulgham, gsherloc, koivisto, simon.fraser, sullivan, zalan
Priority: P2 Keywords: HasReduction, InRadar
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   
URL: https://direct.orange.co.il/selfservice/antiRobot.jsp
Attachments:
Description Flags
Reduction none

mitz
Reported 2007-09-08 14:40:19 PDT
The URL FOUCs when loaded (or reloaded). I am afraid that's a result of <http://trac.webkit.org/projects/webkit/changeset/25308>
Attachments
Reduction (717 bytes, text/html)
2007-09-08 16:19 PDT, mitz
no flags
mitz
Comment 1 2007-09-08 16:19:27 PDT
Created attachment 16230 [details] Reduction See comments in the reduction.
mitz
Comment 2 2007-09-08 16:39:16 PDT
It would be nice, if possible, to not paint those newly-created-while-pending-stylsheets objects (similarly to how *no objects* are painted in initial FOUC suppression). However, it would be bad to go back to not painting anything (that would result in a flash of white). I think this may be doable by having the style selector inject a "visibility: hidden" declaration into all element that do not already have a renderer under the right conditions. Need to be careful not to contaminate or shared styles.
Gavin Sherlock
Comment 3 2007-09-08 20:37:02 PDT
Note, I do see the flashing red square when reloading the test case in released Safari Version 2.0.4 (419.3) on 10.4.10 - it may be a regression from a nightly build, but is not a regression from the released build.
mitz
Comment 4 2007-09-08 23:22:04 PDT
(In reply to comment #3) > Note, I do see the flashing red square when reloading the test case in released > Safari Version 2.0.4 (419.3) on 10.4.10 - it may be a regression from a nightly > build, but is not a regression from the released build. Thanks for testing! I am also seeing the flash in Safari 3.0.3 beta on 10.4.10. However, I cannot reproduce the FOUC at <https://direct.orange.co.il/selfservice/antiRobot.jsp> with that version (so the reduction may be wrong). Can you check if the live site FOUCs with Safari 2.0.4?
Gavin Sherlock
Comment 5 2007-09-08 23:25:56 PDT
I don't see FOUC with Safari 2.04 at the bug URL, so it is a regression, so the test case must obviously be triggering different behavior than the bug URL for some reason (timing related?).
mitz
Comment 6 2007-09-08 23:53:43 PDT
(In reply to comment #4) > However, I cannot reproduce the FOUC at > <https://direct.orange.co.il/selfservice/antiRobot.jsp> with that version (so > the reduction may be wrong). I was able to reproduce the FOUC with the 3.0.3 beta once I enabled autofill for user names and passwords. I then tried the Safari 2 application with the 3.0.3 beta version of the frameworks. The FOUC didn't happen with that combination. (In reply to comment #5) > I don't see FOUC with Safari 2.04 at the bug URL, so it is a regression, so the > test case must obviously be triggering different behavior than the bug URL for > some reason (timing related?). My conclusion is that the underlying WebKit bug is not a regression (and arguably not a bug): there is no FOUC suppression once you have <body> and calculate style in the "no pending stylesheets" state. The reduction demonstrates that. However, as mentioned in the reduction, // Note that on the original orange.co.il page, the layout question comes // from the browser (apparently for autofill). so the reason for the different observed behavior on the URL is a change in the Safari application between 2.0.4 and the 3.0.3 beta. That is something for Apple to investigate, of course.
David Kilzer (:ddkilzer)
Comment 7 2007-09-09 05:49:37 PDT
Antti Koivisto
Comment 8 2007-09-09 18:06:56 PDT
This is "a result of http://trac.webkit.org/projects/webkit/changeset/25308" in the sense that 25308 fixed problems created by http://trac.webkit.org/projects/webkit/changeset/24973 and one of the side effects of those problems was hiding this FOUC. We had the same FOUC before that.
mitz
Comment 9 2007-09-27 05:29:52 PDT
Ahmad Saleem
Comment 10 2022-08-30 09:39:04 PDT
I am not able to reproduce this bug using attached test case when I am refreshing the tab (I tried it in non-private window) as well and it is not showing "red" flash, which is expected and it is same across other browsers (Chrome Canary 107 and Firefox Nightly 106) as well. I am going to mark this as "RESOLVED CONFIGURATION CHANGED" but please reopen if you think I am testing it wrong or this is reproducible by following other test steps or new test case. Thanks!
mitz
Comment 11 2022-08-30 09:43:20 PDT
Thanks for testing. Agreed that this isn’t an issue anymore.
Note You need to log in before you can comment on or make changes to this bug.