996124 - facebook.com - New Login Facebook page shows password and placeholder text overlapped

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Guilherme Lima]

Attachment: screenshot

Facebook recently (at least for me) changed its login page.
And on this new page, the space for the email and password have a placeholder text (on PT-BR they show "Email ou telefone" and "Senha"). But if Firefox have one password saved for Facebook, it puts it on this space automatically. And things overlap each other. If you click somewhere close to the fields, the placeholder text goes away, and everything goes back to normal.
Since I'm not very good at English, I attached a screenshot showing the problem.

Comment 1

[Mats Palmgren (inactive)]

Which version of Firefox are you using?  Does the problem also occur in Firefox 28?

Comment 2

[Guilherme Lima]

(In reply to Mats Palmgren (:mats) from comment #1)
> Which version of Firefox are you using?  Does the problem also occur in
> Firefox 28?

I don't know how Facebook chooses the version of the page it shows. It only shows the new one for me on Nightly. On Beta and on Chrome it shows the old one.

Comment 3

[Mats Palmgren (inactive)]

Faking the UA string in an older Firefox so it looks like Nightly might help.

Comment 4

[Daniel Holbert [:dholbert]]

Seems like this could easily be a bug in Facebook, not in Gecko, though it's hard to tell without being able to reproduce it or compare to other browsers.

Guilherme: You can probably poke at this a bit and find out where the placeholder text is coming from using the Inspector (right-click the textfield and choose "Inspect Element").

For example, it's possible that the placeholder text is a background image, which Facebook is intending to remove as soon as you start typing, but they're failing to do so for some reason. You should be able to find this out in the inspector view by clicking "computed" in the upper-left inspector area, and then typing "background" in the search box at its bottom-right.

Comment 5

[Guilherme Lima]

These?

<div class="uiStickyPlaceholderInput">

    <div class="placeholder" aria-hidden="true"></div>
    <input id="email" class="inputtext _5aju" type="text" aria-label="E-mail ou telefone" value="E-mail ou telefone" tabindex="1" placeholder="" name="email"></input>

</div>

and

<div class="uiStickyPlaceholderInput uiStickyPlaceholderEmptyInput">

    <div class="placeholder" aria-hidden="true"></div>
    <input id="pass" class="inputtext _5aju" type="password" aria-label="Senha" value="Senha" tabindex="2" placeholder="" name="pass">
    </input>

</div>

There is background-image none

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Guilherme Lima from comment #5)
> There is background-image none

OK, that's one theory down then.

> These?
>     <input id="email" class="inputtext _5aju" type="text" aria-label="E-mail
> ou telefone" value="E-mail ou telefone" tabindex="1" placeholder=""
> name="email"></input>

Yeah -- that's not sufficient to trigger the bug, though. (e.g. if I type
   data:text/html,<input [etc etc copypasted from your HTML]>
then I get a textfield that behaves as I'd expect it to.

So, I can't really speculate further about what might be going on. If you like, you might be able to figure something out by live-editing the DOM via the inspector, though (to see if you can fix it, or figure out a way to trigger it in a non-Facebook-hosted testcase).


Also: perhaps you could do a "File | Save Page As", and make sure "Web Page, Complete" is selected in the save dialog, and if the saved copy reproduces the problem, then zip it up and attach the zip file?

Comment 7

[Guilherme Lima]

Attachment: Bem-vindo ao Facebook - acesse, cadastre-se ou saiba mais.htm

On the attached page, the dots (representing the password) don't go away when I focus the password field.
There are no dots on the 'Email' field, because when I saved the page, there were none.

Comment 8

[Guilherme Lima]

Attachment: Bem-vindo ao Facebook - acesse, cadastre-se ou saiba mais.rar

Yeah... opening like an attachment doesn't work.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Guilherme Lima from comment #7)
> On the attached page, the dots (representing the password) don't go away
> when I focus the password field.

That's not surprising (and is different from what your initial screenshot demonstrates).

That just indicates that the field has a default value -- an actual value, not just placeholder text -- the HTML has <input ... value="Senha">. This effectively makes the browser fill in that value to the field, immediately when the page loads, as if you typed that value.  What's happening there is correct/expected.

This is different from the overlapping stuff shown in your screenshot.

Comment 10

[Daniel Holbert [:dholbert]]

The attached RAR doesn't seem to demonstrate the issue, either. Do you see the overlapping issue when you load your saved .htm file, locally?

If not, probably don't bother reposting -- but if so, it should be possible to archive it and post that, but you'll need to include the supporting files (css, JS, etc.) which should be in a folder with the same name as your .htm file. (That's where "Save as ... Web Page, Complete" puts them.)

(Also, IIRC there's no free-software rar extractor, so it's preferred that you post file archives as .zip or .tar.gz if possible)

Comment 11

[Guilherme Lima]

Attachment: Facebook Login Page.zip

Sorry about the .rar extension.

I see the "Senha" and the dots overlapped, even locally, so I'm uploading the folder.

And, of course, on comment 7 I was wrong. Who should go away (but doesn't) it's the "Senha", not the dots.

Comment 12

[Daniel Holbert [:dholbert]]

Thanks! I can reproduce the bug with the contents of the zip file, on first load.

One more question: When you hit this at facebook.com, does this only happen on the *first load* of the facebook page, with the username/password auto-populated via Firefox's password manager, or do you actually hit this when you type into the fields yourself?

Comment 13

[Daniel Holbert [:dholbert]]

Yeah, this looks like a Facebook bug.

If you view the Password field in Inspector, and then click in the field and start typing, you'll see its grandparent change from:
 <div class="uiStickyPlaceholderInput uiStickyPlaceholderEmptyInput">
...to...
 <div class="uiStickyPlaceholderInput">

...and the page source has:
<div class="uiStickyPlaceholderInput uiStickyPlaceholderEmptyInput"><div aria-hidden="true" class="placeholder">Senha</div>
...and the CSS has (abbreviated):
 .uiStickyPlaceholderInput .placeholder{display:none}
 div.uiStickyPlaceholderEmptyInput .placeholder{display:block}

So the removal of "uiStickyPlaceholderEmptyInput" is what makes that text go away.

So basically, they synthesize some placeholder text to be above the field at first (regardless of whether the browser autofills the field), and then they listen for keyboard events to trigger the placeholder to hide.

Moving to Tech Evang, since the fix for this is on Facebook's side. (I don't know offhand precisely how/when password autofilling happens, but that's an event they need to handle with this placeholder text.)

Comment 14

[Adam Stevenson [:adamopenweb]]

Hi Colby. Would you be able to help with this bug?

Comment 15

[Colby Rabideau]

I let the team know about the problem. Thanks for the report!

Comment 16

[Michael Ellis]

Attachment: Screen Shot 2015-01-27 at 3.47.54 PM.png

Comment 17

[Michael Ellis]

Tested this issue today.  Bug seems to have been resolved. (screenshot attached)

Closing this bug - Worked for me.

Comment 18

[Guilherme Lima]

The problem is (was) specific to the new layout of initial page of Facebook.
But I'm not being offered anymore with that layout, so maybe they decided to not use it, I don't know.