expensify add expense form always off the screen

NEW
Unassigned

Status

Tech Evangelism
Mobile
2 years ago
a year ago

People

(Reporter: larsberg, Unassigned)

Tracking

({foxfood})

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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
Keywords: foxfood
Keywords: dogfood
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
Created attachment 8646450 [details]
Screenshot_2015-08-11-11-34-47.png
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]

Comment 6

a year ago
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.
Created attachment 8794125 [details]
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)
You need to log in before you can comment on or make changes to this bug.