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)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jeroendegloire created an issue. See original summary.

jeroendegloire’s picture

Issue summary: View changes
jeroendegloire’s picture

cilefen’s picture

Priority: Major » Normal
Issue tags: -bartik theme, -caching, -Rendering

I don't see it. Did you try on 8.4.x or 8.4.0-alpha1?

jeroendegloire’s picture

Issue summary: View changes
FileSize
46.5 KB
jeroendegloire’s picture

@cilefen Yes it also happens on drupal 8.4.0-alpha1. See gif, same behaviour for all 8.3 and 8.4 drupal versions.

swentel’s picture

I actually have this too, on 8.3.x
always thought this was our own damn fault :)

cilefen’s picture

Version: 8.3.x-dev » 8.4.x-dev

For what it's worth, I am on Firefox 52.0 with no plugins.

@jeroendegloire: you have assigned yourself. Are you working on a patch?

jeroendegloire’s picture

Assigned: jeroendegloire » Unassigned
jeroendegloire’s picture

Issue summary: View changes
andriyun’s picture

Issue tags: -Bartik

I'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.

  if (isset($form['name']['#attributes']['autofocus'])) {
    unset($form['name']['#attributes']['autofocus']);
  }

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

voleger’s picture

FileSize
280.12 KB
327.36 KB

Drupal 8.4.x#9cd1c42
Removing autofocus attribute make no changes to page loading for me.

jeroendegloire’s picture

For me it works

@voleger: in chrome i didn't had this issue..

voleger’s picture

Yes, I can confirm that too.

I had attached examples to see a difference.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

flocondetoile’s picture

Status: Active » Needs review
FileSize
1.68 KB

Hello,

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.

Status: Needs review » Needs work

The last submitted patch, 16: 2900908-16.patch, failed testing. View results

flocondetoile’s picture

Status: Needs work » Needs review
Issue tags: +a11y
FileSize
1.74 KB

Wrong relative path. Tagging with a11y to have some input about the accessibility perspective.

andriyun’s picture

+1 to RTBC

cchoudhary’s picture

Patch in #18 works for me. Tested on drupal 8.5.x-dev.

cchoudhary’s picture

Status: Needs review » Reviewed & tested by the community
catch’s picture

Component: browser system » user.module
alexpott’s picture

Status: Reviewed & tested by the community » Needs review

So reading http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus

I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage.

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

is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.

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.

flocondetoile’s picture

This is exactly the case with the user/login and the user/password pages.

Not 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 :-(

alexpott’s picture

@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

andrewmacpherson’s picture

Issue tags: -a11y +Accessibility
mlncn’s picture

The 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++

qqboy’s picture

patch works
but form_alter function does not work

mgifford’s picture

Status: Needs review » Needs work

So I'm assuming that the status should change based on #28

alexpott’s picture

Status: Needs work » Closed (outdated)

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

sillo’s picture

Issue tags: -Accessibility +accessibility

This issue is not fixed. Why is it closed?
Is there a duplicate?

This issue has been around since D8's first release.

andrewmacpherson’s picture

Issue tags: -accessibility (duplicate tag) +Accessibility

fixing accessibility tag

sibustephen’s picture

FileSize
96.65 KB
120.62 KB

Hi, 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

sibustephen’s picture

Status: Closed (outdated) » Active
sibustephen’s picture

Status: Active » Needs work
sibustephen’s picture

Status: Needs work » Closed (outdated)