Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Firefox loads JS before CSS, causing flash of unstyled content. On IE and chrome I don't have this issue.
First I thought it was an issue with my theme but it also happens with bartik on a clean install.
I think the cause is that firefox loads JS before CSS.
This issue only happens on the user login and reset password pages. (user/login and user/password)
Comment | File | Size | Author |
---|---|---|---|
#33 | normal.png | 120.62 KB | sibustephen |
#33 | distorted.png | 96.65 KB | sibustephen |
#18 | 2900908-18.patch | 1.74 KB | flocondetoile |
#12 | Chrome(62.0.3202.75).mp4 | 327.36 KB | voleger |
#12 | Firefox (56.0).mp4 | 280.12 KB | voleger |
Comments
Comment #2
jeroendegloire CreditAttribution: jeroendegloire commentedComment #3
jeroendegloire CreditAttribution: jeroendegloire commentedComment #4
cilefen CreditAttribution: cilefen commentedI don't see it. Did you try on 8.4.x or 8.4.0-alpha1?
Comment #5
jeroendegloire CreditAttribution: jeroendegloire commentedComment #6
jeroendegloire CreditAttribution: jeroendegloire commented@cilefen Yes it also happens on drupal 8.4.0-alpha1. See gif, same behaviour for all 8.3 and 8.4 drupal versions.
Comment #7
swentel CreditAttribution: swentel at eps & kaas for MuseScore commentedI actually have this too, on 8.3.x
always thought this was our own damn fault :)
Comment #8
cilefen CreditAttribution: cilefen commentedFor what it's worth, I am on Firefox 52.0 with no plugins.
@jeroendegloire: you have assigned yourself. Are you working on a patch?
Comment #9
jeroendegloire CreditAttribution: jeroendegloire commentedComment #10
jeroendegloire CreditAttribution: jeroendegloire commentedComment #11
andriyun CreditAttribution: andriyun as a volunteer and at Bellcom, Drupal Ukraine Community for Drupal Ukraine Community commentedI've found the reason for this bug
The issue is in
autofocus
form element attribute here http://cgit.drupalcode.org/drupal/tree/core/modules/user/src/Form/UserLo...To fix it in your project you can simply remove this attribute in hook_form_BASE_FORM_ID_alter() inside module or theme.
Or use login block instead.
The form inside this block doesn't have this attribute
http://cgit.drupalcode.org/drupal/tree/core/modules/user/src/Plugin/Bloc...
Comment #12
volegerDrupal 8.4.x#9cd1c42
Removing autofocus attribute make no changes to page loading for me.
Comment #13
jeroendegloire CreditAttribution: jeroendegloire commentedFor me it works
@voleger: in chrome i didn't had this issue..
Comment #14
volegerYes, I can confirm that too.
I had attached examples to see a difference.
Comment #16
flocondetoileHello,
thanks @andriyun. #11 fix the issue.
I have same issue on FireFox and spent long hours to figure why theses pages (user login, reset passwork, checkout login) with some input fields were scrolling to the form, after an horrible blinking effect.
I don't think adding an autofocus property on the input is really a good idea. See for exemple http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus. Espcially if these autofocus breaks completely the page during the loading time.
In fact the autofocus is even removed from the block login. So why add a property to remove it just after.
Here a patch which remove theses properties and which could prevent us to have some ugly debug moment.
Comment #18
flocondetoileWrong relative path. Tagging with a11y to have some input about the accessibility perspective.
Comment #19
andriyun CreditAttribution: andriyun at Bellcom, Drupal Ukraine Community commented+1 to RTBC
Comment #20
cchoudhary CreditAttribution: cchoudhary at ]init[ AG commentedPatch in #18 works for me. Tested on drupal 8.5.x-dev.
Comment #21
cchoudhary CreditAttribution: cchoudhary at ]init[ AG commentedComment #22
catchComment #23
alexpottSo reading http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus
This is exactly the case with the user/login and the user/password pages. Auto-focussing on the first form element here is a usability win. For pages it
To me this looks like a firefox bug not a Drupal bug - which unfortunately is still happening in Firefox 58. And here is the firefox bug report https://bugzilla.mozilla.org/show_bug.cgi?id=712130 - interestingly they committed a fix 21 days ago but had to back it out because of failures on Android. I guess the question is should we be making ourselves less usable because of a Firefox bug or just wait for them to fix it.
Comment #24
flocondetoileNot exactly. We can't assert what is put on theses pages. Some sites can put some instructions, some informations, or what they want on theses pages. Not only the form. And as FF scroll directly to the first input element (even if there was not this "flashy" bug), these elements can be hide to the end user.
But yes if FF fix the double bug (flash styling and automatically scroll to the autofocused element), then there is not anymore issue :-)
But the FF bug seems to be 6 years old...
Edit: and even, if this is FF bug, end users don't care : it's the Drupal site which seems buggy :-(
Comment #25
alexpott@flocondetoile you might be right that we might not want to auto-focus but none of the reviews goes into the accessibility pluses and minuses of removing it.
Our pages are titled correctly and the form has the appropriate help. Reading Bruce's blogpost I think we conform to expectations. Yes we can't know what sites stick on there login or password reset page and if the sole intent of those pages becomes not to log in or reset the password then they can remove the auto-focus because I'd hazard a guess that is an extremely minor use-case.
This was added for usability in #20446: Cursor focus on user login page and there is a wider discussion of the accessibility of auto-focus in #2861374: Inconsistent user interface with focusing fields
Comment #26
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedComment #27
mlncn CreditAttribution: mlncn at Agaric for Drutopia, Teachers with GUTS, MASS Design Group commentedThe Firefox bug is resolved as fixed in Firefox 60! https://bugzilla.mozilla.org/show_bug.cgi?id=712130
Patch from #18 works in the meantime.
flocondetoile++
Comment #28
qqboy CreditAttribution: qqboy commentedpatch works
but form_alter function does not work
Comment #29
mgiffordSo I'm assuming that the status should change based on #28
Comment #30
alexpottWe also need to decide if we want to change the auto-focus in light of the fact it is now fixed in Firefox. If we do then this issue should be changed to a task and the issue summary updated and this issue should be re-opened.
As the the bug reported in the current issue summary and title is no longer I'm closing this issue.
Comment #31
sillo CreditAttribution: sillo commentedThis issue is not fixed. Why is it closed?
Is there a duplicate?
This issue has been around since D8's first release.
Comment #32
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedfixing accessibility tag
Comment #33
sibustephen CreditAttribution: sibustephen as a volunteer commentedHi, this issue is reproducible on Firefox 69.
Steps to reproduce -
1) Open Firefox, and open the Drupal Site as an anonymous user.
2) First Case - On load of the page, the static HTML content appears for a fraction of milli second
3) Second case - on refreshing the browser continuously, the static HTML appears for a fraction of milli second and then restores as usual.
4) Works fine for admin interface.
Is there any follow up ticket created for this case ?
Thank you
Comment #34
sibustephen CreditAttribution: sibustephen as a volunteer commentedComment #35
sibustephen CreditAttribution: sibustephen as a volunteer commentedComment #36
sibustephen CreditAttribution: sibustephen as a volunteer commented