webcompat / web-bugs

A place to report bugs on websites.
https://webcompat.com
Mozilla Public License 2.0
742 stars 65 forks source link

www.facebook.com - The 'Guests can invite friends' section is not centered #6213

Open softvision-sergiulogigan opened 7 years ago

softvision-sergiulogigan commented 7 years ago

URL: www.facebook.com Browser / Version: Firefox Mobile Nightly 55.0a1 (2017-04-25) Operating System: Samsung Galaxy Note 4 (Android 5.0.1) Problem type: Layout is messed up

Steps to Reproduce

  1. Navigate to: www.facebook.com
  2. Login with valid credentials.
  3. Tap the Hamburger button (Top-Right).
  4. Tap the Events option.
  5. Tap the Create Event button.
  6. Hide the keyboard. Observe the 'Guests can invite friends' section.

Expected Behavior: The 'Guests can invite friends' section is centered.

Actual Behavior: The 'Guests can invite friends' section is not centered.

Notes:

  1. The issue is also reproducible on on Firefox 52.0 Release (Mobile).
  2. The issue is not reproducible on Chrome (Mobile) 57.0.2987.132.
  3. Screenshot attached.

Watchers: @softvision-oana-arbuzov @softvision-sergiulogigan

sv; country: fr

Screenshot Description

From webcompat.com with ❤️

MDTsai commented 7 years ago

Confirmed, I think it's controlled by:

.touch ._52we {
    align-items: center;
}

Works for Firefox desktop in responsive design, move to needsdiagnosis.

softvision-sergiulogigan commented 6 years ago

The issue is still reproducible. Tested on Huawei P10 (Android 7.0), Firefox Nightly 59 and Chrome 63.

wisniewskit commented 6 years ago

They're serving different markup to Firefox UAs. The markup they serve to Chrome UAs works fine in Firefox, and the markup they serve to Firefox renders just as wrong in Chrome, so this isn't a webcompat issue proper. They should just serve the same markup to Firefox:

<label class="_5f25 _2pi9 touchable _skt" data-sigil="guests_can_invite_friends touchable">
  <div class="_52jd _55wp _4g33 _52we _5f2a _5xou" role="radio" aria-checked="true">
    <div class="_4g34">Guests can invite friends</div>
    <div class="_5s61 _5f2b" style="align-self:flex-start; margin-top: 20px;">
      <input type="checkbox" aria-hidden="true" name="guests_can_invite_friends" checked="1">
      <div class="_5f26"></div>
    </div>
  </div>
</label>

Instead of what they're serving:

<label class="_5f25 _2pi9 touchable _skt" data-sigil="guests_can_invite_friends touchable" data-store-id="60">
  <div class="_52jd _55wp _5909 _5f2a _5xou" role="radio" aria-checked="true">
    <div class="_4g33 _52we">
      <div class="_4g34">Guests can invite friends</div>
      <div class="_5s61 _5f2b" style="align-self:flex-start; margin-top: 20px;">
        <input type="checkbox" aria-hidden="true" name="guests_can_invite_friends" checked="1">
        <div class="_5f26"></div>
      </div>
    </div>
  </div>
</label>

The reason they're doing this is probably because of the interop issue fixed in bz958714, because that extra <div class="_4g33 _52we"> has the styles display:flex; height:100%; width:100%. They no longer need this as of Firefox 60 (though it's up to them if they wish to still serve this markup to older versions of Firefox).

However, they need to take care to have a -moz-appearance:none rule to prevent a double checkbox from appearing, as right now it doesn't look as though their Chrome version is served that rule (though the Firefox version does). It may be as easy as altering this stylesheet rule:

._5f2a input[type="checkbox"], ._5f2a input[type="radio"] {
  -webkit-appearance:none;
  -moz-appearance:none;
  /* etc */
}

That said, there is an even worse problem here: the checkbox/label are not properly interactive in Firefox, regardless of the version it is served. Sometimes it doesn't seem to react to the taps/clicks, and it looks like it may be caused by something in their event handling. I'm investigating that right now.

wisniewskit commented 6 years ago

Aw nuts, I spent a couple of hours diagnosing the checkbox-tapping issue only to ultimately find myself remembering that I've diagnosed it before when I spotted a variable named USE_SYNTHETIC_CLICKS. Sure enough, that diagnosis was done in #6214 (which is in sitewait).

So yeah, they will need to fix that as well as what I suggested in my previous comment in this issue.

adamopenweb commented 6 years ago

Reaching out to our contact from bug #6214.

miketaylr commented 5 years ago

Still an issue, though a minor one.

cipriansv commented 5 years ago

I retested the issue and it is still reproducible on my side.

image

Tested with: Browser / Version: Firefox Nightly 68.1a1 (2019-08-17), Firefox Preview 1.2.0 (Build #12181645) Operating System: Huawei P10 (Android 8.0) - 1080 x 1920 pixels (~432 ppi pixel density)