1595435 - bankhapoalim.co.il login - can't enter username or password

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Itamar]

On https://www.bankhapoalim.co.il/ when you first load the page you cannot enter a username nor a password.

1. Open a new tab and navigate to https://www.bankhapoalim.co.il/
2. The cursor will be in the user name field
3. try to type -> No characters will appear in the user name field.
4. Try to move the cursor to the password field and type -> No characters will appear in the user name field.
5. Click on another tab and get back to the first tab.
6. type again -> now you can enter the username and password.

---

Note that when you try to enter characters and can't trying to move from one TextField and another using the tab ket does not work either.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm assuming the username field is the one labeled "קוד משתמש" and the password field is the one labeled "סיסמה".

I managed to get the bug to happen once, but I can't get it to happen again, so it's a bit hard to debug... or even to tell whether it belongs in the Layout: Form Controls or DOM: Events component.

Do you know if this also happens in browsers other than Firefox, or if it only happens in Firefox?

Comment 2

[Itamar]

Yes, you are correct on your assumption.
I can reproduce this on 2 PCs.
I just need to open a new tab or refresh a tab that has this website already open.
I have also tried firefox in safe mode with the same result.

Try to close firefox alltogether and reopen it and see if you can reproduce this.

I tested on Chrome, Edge & internet explorer.
None of them have this problem.
What I do see different from firefox is that once the website is loaded the focus and cursor seems to be on the "קוד משתמש" (username) for a second and then both username and password become gray and lose the focus.
In firefox, the focus stays in the "קוד משתמש" field.

Comment 3

[Matthew N. [:MattN]]

Hello, which operating system are you using?

Comment 4

[Itamar]

Windows 10 - Home 1903
But I can reproduce this on Windows 7 laptop I have here.
It's a problem I know of for a long time (more than a year) but since its a small issue I never reported it.

Comment 5

[Sean Voisen (:svoisen)]

Mike: Is this something your team can look into?

Feels like a DOM bug but will leave in Layout for now.

Comment 6

[Mike Taylor [:miketaylr]]

I'm not able to reproduce the bug as reported. What I observe is the following:

In Chrome, on page load the username input has focus for a split second, then it disappears. document.activeElement is <div id="INDblindNotif" class="INDhiddenText" tabindex="-1" role="alert">.

In Firefox, I don't visually observe the focus change, but instead <div id="INDblindNotif" class="INDhiddenText" tabindex="-1" role="alert"> is the activeElement just like in Chrome.

I'm testing in a fresh profile in Nightly with no addons installed. zip13, does the bug reproduce for you in Firefox Nightly as well?

Comment 7

[Itamar]

Well strange.
I installed nightly on a VM and I could reproduce it just the first time like David. Then I could not reproduce it again.
I then Installed the nightly on my main laptop and could reproduce it without any problem.
Every time I go into the website I can reproduce the problem.
I'm attaching a clip showing what I'm doing.
Note that every time I move between the username and password fields I also try to enter characters with the keyboard.
only after I click on an area out of the user name and password and get back to it I can enter text.
You can see the clip here(too big to attach):
https://app.box.com/s/lhpru0qi3wal8j4bnehyov1j2duqmr8b

Comment 8

[Mike Taylor [:miketaylr]]

Thanks for the video. I still get expected results on macOS or Windows... Do you have any errors in the web console by chance? Do you know if you have your input language set to something different?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I can repro on Linux pretty easily (stock Fedora with en-US locale). I can try to bisect this tomorrow if nobody gets there earlier.

Comment 10

[Itamar]

(In reply to Mike Taylor [:miketaylr] from comment #8)

Thanks for the video. I still get expected results on macOS or Windows... Do you have any errors in the web console by chance? Do you know if you have your input language set to something different?

Just went to work this morning where I use FF 71 (Just updated)
I can reproduce without any problem.
I have both Eng and Heb locales installed on the machine and when I open the website the language is set to ENG.
This is from the console:

[IND] You are running Firefox browser, version: 71 accessibility.js:5:52
[IND] $IND jQuery version: 2.2.4 accessibility.js:5:52
The script from “https://login.bankhapoalim.co.il/CAClientPages/ca/loginAravit_files/getFileJs(2).jsp” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.
poalwwwc
The script from “https://login.bankhapoalim.co.il/CAClientPages/ca/newLogin_files/getFileJs.jsp?v=V15” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.
poalwwwc
The script from “https://login.bankhapoalim.co.il/CAClientPages/ca/newLogin_files/getFileJs(1).jsp?v=V15” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.
poalwwwc
Loading failed for the <script> with source “https://www.bcodes.co.il/iMAWebCookie.js?2e98eb61-1646008a944-be7239722bf9e6184ab469c11075fd86&h=www.pages06.net”. www.bcodes.co.il:9:1
unreachable code after return statement
getFileJs(1).js:231:2
unreachable code after return statement
vads.js:1:486
unreachable code after return statement
vads.js line 1 > eval:1:486
The script from “https://login.bankhapoalim.co.il/CAClientPages/new_images/JSP_BANK/vsenc.jsp?aaa=0.8204113372087513” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.
poalwwwc
The script from “https://login.bankhapoalim.co.il/CAClientPages/new_images/JSP_BANK/vsenc.jsp?aaa=0.08403722995768659” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.
poalwwwc

​

Comment 11

[Emilio Cobos Álvarez (:emilio)]

This is still broken all the way back to FF53 (and earlier builds crash on my machine).

My best theory is that they're doing something weird with window focus which prevents the editor from working... Masayuki, have you seen anything like this before, where input is focused but you cannot input anything? I can poke at debugging this if you don't know off-hand, just ni? me back.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I remembered bug 1450055.

From point of view of DOM Event module, same thing still occurs if some chrome script handles focus event before editor and stops propagation of the event, same symptom can occur. However, I guess there is no such system event listener since such listener should cause similar bugs in a lot of websites.

Another possible thing is, EditorEventListener::Focus() meets something unexpected situation. If text control element is reframed while dispatching a focus event, there might be no valid EditorEventListener instance because TextControlState::UnbuindFromFrame() makes TextEditor disconnect existing EditorEventListener, but TextControlState::BindToFrame() may reinitialize TextEditor later (asynchronously). If so, TextControlState::PrepareEditor() needs to notify editor of getting focus if the text control element is focused.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case (focus the input before the timer fires)

I found a repro for this. The issue is that:

• We focus the <input> element.
• Something at some point on the outer page it calls someRandomElement.focus().
• We hit this case where the focus can't be stolen.
• But! We change the calling window's focused element here, which means we're now on a broken state, because the focused element of the iframe window is not the <iframe>, so nsFocusManager::GetFocusedDescendant will stop at the <div>, instead of going to the <iframe>'s window and sending the key events there.

This looks pretty broken.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1595435 - Allow content to steal focus from a cross-origin iframe. r=masayuki

This matches other browsers.

Keep the restriction just to chrome nodes, and in that case, avoid getting into
the broken state, which is what causes the issue. I'm not sure if this even
matters anymore given e10s but...

Comment 15

[Emilio Cobos Álvarez (:emilio)]

self-ni? to check some focus-stealing behavior.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f223bcdf893
Allow content to steal focus from a cross-origin iframe. r=masayuki

Comment 17

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/5f223bcdf893

Comment 18

[Itamar]

Tested on nightly 73.0a1 (2019-12-25)
It seems to work and behave like in Google Chrome and MS Edge.
The focus is on the username field for a moment and then disappears.
Clicking on it or the password field with the mouse regains focus and allows entering of text.