Issue metadata
Sign in to add a comment
|
Elements not getting the focused state on page with basic auth
Reported by
varga.lu...@gmail.com,
Jul 10 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Visit a page protected with basic auth 2. Enter the correct auth 3. Try and click on an input that has a specific :focused state (eg., CSS changes background for input:focused to red) - input should get a red background but instead stays as it is 4. Open developers console 5. Click on the input again, this time, it will get a red background. 6. refresh page 7. Click on input again, it'll again receive a red background 8. Close the entire browser 9. Open browser 10. log in with basic auth 11. click on input, input again won't change colour until you: resize browser, open dev tools, minimize browser, open a new tab, change tab and then click on the input again What is the expected behavior? Clicking on the input should toggle 'focused' element state. What went wrong? When a user comes on a website I am developing, the user cannot focus any element (via mouse click, if they focus it via tabbing, the elements don't get the 'focused' state either) and that's only an issue in Chrome. That is, until the user resizes the window, minimizes the window, opens a new tab, opens developer tools, etc. Reloading the page does nothing. However, as soon as focus is "enabled", the user can navigate/refresh with purging cache, etc., close the browser and open it again, and everything works normally - the elements get the 'focused' state normally. This behaviour only happens in Chrome on a page protected with basic auth. There are no custom event listeners that would listen for the 'resize' event. There are no errors in console and all javascript that doesn't depend on focused element state gets executed correctly. Hover events and all CSS styling that depends on hovered state all work correctly. After clicking on an input, it is possible to write things in the input. The only thing that made the problem go away was removing the basic auth. I also find it extremely odd that basic auth would interfere with the focused state of elements, especially as the error persists after you refresh and only goes away as soon as you interact with browser itself (minimize, open new tab, do anything that resizes your browser window or document), after that it works correctly and there are no errors whatsoever. I also tried to add autofocus property to an input element and it doesn't get focused. I also tried disabling JS, to be absolutely certain there's nothing in my JS that would interfere with the elements receiving :focused state, and the issue persists. Did this work before? Yes Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: Basically it seems that no matter what one does, the elements won't get the 'focused' state until you do something with the browser itself, afterwards, everything works as it should even after one refreshes the page. However, before you do something with the browser itself, you cannot make the elements get focused state even after reloads. The same problem happens on mobile chrome
,
Jul 11 2017
Please visit http://navigheaza.ro/auth-bug/ to reproduce User: user Password: password
,
Jul 11 2017
Thanks alexander for providing the test sample - I am having identical issues on mobile and in Chrome (opening in incognito mode) as on the website I am developing. The problem is persistent both on iOS Chrome (mobile and Mac) and on Windows Chrome (desktop) and Chrome in Andriod
,
Jul 11 2017
Thank you for providing more feedback. Adding requester "manoranjanr@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 12 2017
If i understand correctly the test case at http://navigheaza.ro/auth-bug/ the input fields should not become outlined with red after user focuses one of them.... But they do get the outline for me (chrome on android).
,
Jul 12 2017
Stefan, correct. Can you try using incognito mode? I was using incognito mode for testing.
,
Jul 12 2017
Yes, as soon as you interact with the browser itself (switching tabs, minimizing, etc.), the elements get focused correctly. Prior to that, they don't. On mobile, my keyboard shows up, but I am not able to input anything. On desktop, I am able to input text, even though the element isn't in focused state and the red border thus isn't visible.
,
Jul 13 2017
I am also facing same issue in my all application which are using window authentication. Do we have any temporary solution for this ?
,
Jul 13 2017
Well, yeah, I created a hack workaround - although it might not be perfect for every use case, here's what you can do. The goal is to, somehow, interact with the browser outside of the current page, to make it somehow lose focus. You cannot use JS to minimize browser, cannot resize it, cannot open dev tools. What you can do, though, is open a new window. Of course, if you open a new window immediately, a pop-up blocker (as most people have it) will block it and the window itself (or rather your current tab) won't lose focus. Opening a new window can only be done as a reaction to a user event (without triggering potential pop-up blocker). So, without further ado, you can find the workaround I just implemented in the picture (didn't want to post it as .text or .js file in case it may be blocked or something) You can remove turbolinks:load on document, of course - I use turbolinks in my project so that's why they are there. I also use some browser detection so the code will only be executed for Chrome and, using server-side conditioning, only for builds that include basic auth. What the code does, quite self evidently, is that as soon as a user clicks on an input, it opens a new tab and quickly closes it, 1ms later. To prevent this from happening all the time, on every page load, sessionStorage, which gets cleared automatically after tabs from that domain are closed, is used (and we've already established that once focus starts working correctly, it will work as long as you keep your browser open). The effect of this code is that the user will see a quick white flash the first time he clicks on the input, but everything will work correctly :)
,
Jul 14 2017
Thanks At least we can give temp solution to user.
,
Jul 17 2017
,
Sep 29 2017
,
Sep 29 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Jul 10 2017