657614 - No form helper zoom on tap of field input

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Description

[Aaron Train [:aaronmt]]

Build: Mozilla/5.0 (Android; Linux armv7l; rv:6.0a1) Gecko/20110517 Firefox/6.0a1 Fennec/6.0a1

Device: HTC Nexus One
Android: 2.3.4
Keyboard: Android Stock

Currently with the above build, on tap of any content input field there is no form assistant zoom to the particular field.

EX: Zoom (like 4.0.1) to the input field 
AR: No zoom

Tested on: 
* http://contacts.google.com
* http://ncix.com (search field)
* http://canadacomputers.com (search field)

Comment 1

[Aaron Train [:aaronmt]]

Guessing bug Bug 656373

http://hg.mozilla.org/mozilla-central/rev/a6391aea48e5

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #1)
> Guessing bug Bug 656373
> 
> http://hg.mozilla.org/mozilla-central/rev/a6391aea48e5

Good guess I believe. :)

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #2)
> (In reply to comment #1)
> > Guessing bug Bug 656373
> > 
> > http://hg.mozilla.org/mozilla-central/rev/a6391aea48e5
> 
> Good guess I believe. :)

But it just landed. Did the patch actually get into the nightly build?

Comment 4

[Aaron Train [:aaronmt]]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Guessing bug Bug 656373
> > > 
> > > http://hg.mozilla.org/mozilla-central/rev/a6391aea48e5
> > 
> > Good guess I believe. :)
> 
> But it just landed. Did the patch actually get into the nightly build?

Yeah, http://hg.mozilla.org/mozilla-central/shortlog/69597

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

Maths was wrong :)

My concern with this patch is that it thought the desktop build is a tablet, do I have done another error with math? (the code reports 127 dpmm for deskop build)

Comment 6

[Matt Brubeck (:mbrubeck)]

(In reply to comment #5)
> My concern with this patch is that it thought the desktop build is a tablet,
> do I have done another error with math? (the code reports 127 dpmm for
> deskop build)

displayDPI is usually 96 on desktop platforms, and 480p / 96ppi * 25.4mm/inch = 127mm.

In bug 656973 (preference UI), we ended up using 124mozmm as the "tablet" threshold on Android, and 1024px as the "tablet" threshold on other platforms.  This is necessary because our chrome theme uses mozmm on Android and px on other platforms.  On non-Android platforms, it acts like the display is 240dpi when really it is 96dpi.  This throws off anything that wants to use mozmm or displayDPI for chrome elements on non-Android platforms.

For a long-term solution, we should use mozmm and real dpi by default on all platforms, and maybe provide an add-on for Fennec desktop that helps developers simulate different screen sizes and densities.

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v0.2

Well let's consider device with 96 dpi are not tablet.

Comment 8

[Matt Brubeck (:mbrubeck)]

(In reply to comment #7)
> Well let's consider device with 96 dpi are not tablet.

How about "if (dpi <= 96) return (window.innerWidth > 1024);" so it works roughly the same as the preference UI.  And we can file a followup bug to fix this all to work more consistently on desktop.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 533313 [details] [diff] [review]
Patch v0.2

Let's use Matt's tweak for now:

if (dpi <= 96)
  return (window.innerWidth > 1024);

r+ with that

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

http://hg.mozilla.org/mozilla-central/rev/d9080dd8b3f2

Comment 13

[Aaron Train [:aaronmt]]

Verified fixed
Build: Mozilla/5.0 (Android; Linux armv7l; rv:6.0a1) Gecko/20110520 Firefox/6.0a1 Fennec/6.0a1