1373826 - Wifi purchase form onboard IcelandAir broken (credit card textfields in flex container are too wide)

Status: RESOLVED DUPLICATE of bug 1316534

(Core :: Layout, defect, P3)

Description

[u597127]

User Agent: Mozilla/5.0 (Android 7.0; Mobile; rv:54.0) Gecko/54.0 Firefox/54.0
Build ID: 20170608225136

Steps to reproduce:

Used wifi onboard icelandair flight.
Tried to purchase internet access 
https://wifi.icelandairwifi.com/purchase
The credit card form is broken in Firefox Android, both portrait and landscape.
The field for the number is split into 4 pieces, and only partially visible on screen.
It is possible to enter the number, but then the left hand side of the page is no longer visible.
It is impossible to scroll the page to left. It is impossible to complete filling out the form.

It works fine with Chrome for Android. All parts of the form are visible on screen at the same time.



Actual results:

Parts of page become inaccessible


Expected results:

Either render all form fields in visible area, or ability to scroll page back to the left.

Comment 1

[u597127]

The problematic URL likely cannot be accessed from outside the plane. I used the addon "save page" to save a snapshot of the page and hopefully all the scripts that are involved. I will attach a zip.

Comment 2

[u597127]

Attachment: icelandair-wifi-purchase.zip

Comment 3

[Bogdan Surd, QA [:bsurd, NI]]

Hello,

 Using the files provided by [e-mail] I can confirm this.

Comment 4

[Bogdan Surd, QA [:bsurd, NI]]

Attachment: landscape.png

Comment 5

[u597127]

I'm back home.

It's possible to partially reproduce the issue with regular Firefox for Desktop, too, if you resize the window to make it very narrow, so that only the left 2 CC number fields are visible.

After you enter 0000 0000 0000 0000
the left hand side of the credit card form is scrolled out.

There isn't any visible mechanism to scroll to the left.

On Desktop Firefox this can be fixed by pressing the "tab" key. I don't know if I could have used a tab key on the Android keyboard, at least I didn't have that idea.

Comment 6

[Wesly Huang (EPM)]

[triage@July 5th] per comment#5 this may be a common issue in desktop?

@Bogdan: would you help verify if this is seen on Desktop first? thanks.

Comment 7

[Bogdan Surd, QA [:bsurd, NI]]

Attachment: Capture.JPG

Hello,

 I can confirm this is also happening on desktop, as mentioned in Comment 5 the used can get around this by pressing on the tab key.

Comment 8

[Wesly Huang (EPM)]

Thank you, Bogdan. Would you mind also help log a bug for desktop? If this is common then I'm afraid this bug will eventually depends on desktop team to fix it first.

Comment 9

[Bogdan Surd, QA [:bsurd, NI]]

Hello Wesly,

Logged Bug 1379107 for desktop.

Comment 10

[Wesly Huang (EPM)]

[triage@0712] per comment 9, will rely on Desktop to fix it first.

Comment 12

[Daniel Holbert [:dholbert]]

Reopening & reclassifying (& reversing the dupe relationship), since there was no need for a second bug in the first place.

I'm taking a look at this from a gecko layout perspective; more info shortly.

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a reduced testcase.

Expected rendering: orange-bordered textfields should all be inside of the purple-bordered container.
Actual rendering: the orange-bordered textfields overflow off the right side of the purple container.

Notes:
Here and in the original testcase, these input elements have a rule saying "width: 39px".

I think the spec says that this explicit "width" value is supposed to create an upper-bound for what its "min-width:auto" value resolves to.  (Even if the min-content size is larger than 39px, min-width:auto should just resolve to 39px in the presence of this explicit "width" declaration.)

So I think this is a Firefox flexbox bug. This might have been filed previously, but I can't find another version of this bug right away (just looked around a bit).

Comment 14

[Daniel Holbert [:dholbert]]

(Edge and Chrome each produce the "Expected rendering" on the attached testcase. Firefox 54 & Nightly 56 produce "Actual rendering".)

Comment 15

[Daniel Holbert [:dholbert]]

Ah yes, so this is basically the same as bug 1331692, which boils down to a spec-rewrite tracked in bug 1136312.

I'll mark this as a dependency of bug 1136312 for now, and then we can circle back and either dupe or follow up once bug 1136312 is fixed.

Comment 16

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 17

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 18

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Firefox 83 (in layout debugger) vs Chrome 87.png

Here a screenshot loading the testcase in comment 13. This bug should be fixed by bug 1316534.