Closed Bug 1178110 Opened 9 years ago Closed 5 years ago

expensify add expense form always off the screen

Categories

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

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1423709

People

(Reporter: larsberg, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [bzlite][triagr] [needsdiagnosis])

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

If you add a new expense in expensify, the left quarter is off the screen in either orientation and cannot be selected
Flags: needinfo?(fxos.triage.webcompat)
Whiteboard: [bzlite] → [bzlite][triagr]
Flags: needinfo?(fxos.triage.webcompat)
Flags: needinfo?(fxos.triage.duplicate)
QA Whiteboard: [foxfood-triage]
The same thing reproduces in Fennec, so let's move it to Tech Evangelism for further diagnosis.
Component: Gaia::Feedback → Mobile
Flags: needinfo?(fxos.triage.webcompat)
Flags: needinfo?(fxos.triage.duplicate)
Product: Firefox OS → Tech Evangelism
Does the unprefixing service make a difference here?
Nope, doesn't seem to. (In a Nightly Fennec you can set "layout.css.unprefixing-service.globally-whitelisted" to true to enable it.)
This probably requires an account on expensify
Let's ask mike for a diagnosis.
Flags: needinfo?(miket)
Whiteboard: [bzlite][triagr] → [bzlite][triagr] [needsdiagnosis]
Use firefox android open expensify, you will see link to download mobile app or go to full site. I choose full site and it's still the same as :miketaylr 's screenshot.
Attached image Fennec vs Chrome
Yep, still reproducing (the site has reproduced a bit). And Chrome for comparison.
Flags: needinfo?(miket)
So, looking at this... I'm not sure it's a TE bug, possibly a Fennec bug viewport bug? 

You can reproduce the Mobile behavior in Desktop by making the viewport smaller (responsive design mode, etc. -- desktop doesn't honor meta viewport) -- and Chrome desktop behaves the same as Firefox desktop and Fennec (until you turn on their device emulator, which does honor meta viewport).

The site has:
<meta name="viewport" content="width=device-width">
#header has min-width: 800px; width: 100%.
body has min-width: 1000px !important;

kats, am I overlooking something? (Unsure if Canada uses Expensify...)
Flags: needinfo?(bugmail)
Wondering if it's part of http://www.otsukare.info/2016/09/06/viewport-differences-mobile


* Better define the interaction between innerWidth/Height and the meta viewport tag
  https://bugzilla.mozilla.org/show_bug.cgi?id=617034
(In reply to Mike Taylor [:miketaylr] from comment #8)
> The site has:
> <meta name="viewport" content="width=device-width">
> #header has min-width: 800px; width: 100%.
> body has min-width: 1000px !important;
> 
> kats, am I overlooking something? (Unsure if Canada uses Expensify...)

So if I understand correctly, because there's no initial-scale specified, the "auto" procedure is supposed to be used. The spec [1] doesn't mandate any particular way to implement this, but says that one way to do it is to set the initial scale to "initial viewport width / rendered width" which in this case would be 480 / 1000 (assuming a device width of 480px and that the body is the widest thing on the page at 1000px). This is likely what Chrome is doing. We don't do this, though - we set the initial scale to "initial viewport width / actual viewport width", so if the meta-viewport tag has width=device-width we do 480 / 480 and render it at 1.0 zoom.

I think changing our behaviour here would be nontrivial, because the notion of "rendered width" requires running a layout first to see how wide the page ends up being. That means that if we start displaying content to the user incrementally then we might end up changing the zoom partway through page load which can be annoying to the user. It also delays the point at which we can really know what the initial zoom should be. Personally I would prefer having the spec prescribe what we do, but I doubt other browser vendors are going to change their behaviour on this either.

[1] https://www.w3.org/TR/css-device-adapt-1/#handling-auto-zoom
Flags: needinfo?(bugmail)
Depends on: viewport-compat
Priority: -- → P3
Removing b2g specific metadata
QA Whiteboard: [foxfood-triage]
Keywords: foxfood
Based on comment 10, it sounds like this may have been fixed by bug 1423709. Lars, can you confirm if the issue is fixed in latest Fennec Nightly (or a 65 Beta)?
Flags: needinfo?(larsberg)

Confirmed fixed in Firefox Reality 1.1.1 (65 Nightly).

I don't know if that's good enough, but VR headsets are the only android devices I have access to anymore :-) This was originally an FFOS bug.

Flags: needinfo?(larsberg) → needinfo?(botond)

Cool, thanks! That's good enough for me, I'll close this as a dupe.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(botond)
Resolution: --- → DUPLICATE
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: