887555 - [Leo][Here Maps][About][Terms] User needs to zoom in when tapping on Advertisements to read context

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect, P4)

Description

[Jeni]

Zoom-in is needed to read context in Advertisement

Repro Steps:
1) Updated to Leo Build ID: 20130620160852
2) Open Here Maps
3) Click on Option button (Top Left Corner)
4) Tap on 'About'
5) Tap on 'Advertisements'
6) View what is listed

Actual:
When clicking on Advertisements user has to zoom in to read context

Expected:
Context is eligible and able to read without using the zoom in method 

Environmental Variables
Gecko: /rev/
Gaia: ef85283d8a041cecf9a37348cf6a0b580804f3d6
Platform Version: 18.1

Notes:
Issue also occurs in Personal Data page
Repro frequency: 100%

Comment 1

[Pawel Wojciechowski]

I have a problem to reproduce this issue. What do you mean by "Advertisements" on "About" page? Could you attach a screenshot and add the version number of HERE Maps?

Comment 2

[Jeni]

(In reply to pawel.wojciechowski from comment #1)
> I have a problem to reproduce this issue. What do you mean by
> "Advertisements" on "About" page? Could you attach a screenshot and add the
> version number of HERE Maps?

I am sorry I forgot a step.....

Repro Steps:
1) Updated to Leo Build ID: 20130620160852
2) Open Here Maps
3) Click on Option button (Top Left Corner)
4) Tap on 'About'
5) Tap on 'Advertisements'
6) Tap on 'Nokia Service Terms'
7) View what is listed

Screen shots of what you see are below.

Comment 3

[Jeni]

Attachment: Screenshot of issue

Comment 4

[Jeni]

Attachment: Second screenshot of issue

Comment 5

[Jeni]

Version number is 1.8.44

Comment 6

[Pawel Wojciechowski]

Thank you Jeni, now I can reproduce it. The order of repro steps is slightly different:

2) Open Here Maps
3) Click on Option button (Top Right Corner)
4) Tap on 'About'
5) Tap on 'Nokia Service Terms' (or 'Service Terms' in HERE Maps version 1.8.67)
6) Tap on 'Advertisements'
7) View what is listed

Comment 7

[Jeni]

Issue repros on v08m

Leo Build ID: 20130721095109
Gecko: /rev/
Gaia: 47872e74e310a8b575ab39f1a9f334e229be995c
Platform Version: 18.1

When user clicks on 'Advertisements' user has to scroll in view what is listed

Comment 8

[Jaime Vega]

what is the status of this bug?

Comment 9

[Donovan Preston [:fzzzy]]

I was able to reproduce this on build 18.1 20130921041201.

Pawel, any update on this getting fixed?

Comment 10

[Pawel Wojciechowski]

Hi Donovan,

This issue is not fixed yet but we will take care of it within the next couple of weeks. If you want to raise a priority of this issue, please let us know.

Cheers,
Pawel

Comment 11

[Donovan Preston [:fzzzy]]

(In reply to Pawel Wojciechowski from comment #10)

> This issue is not fixed yet but we will take care of it within the next
> couple of weeks. If you want to raise a priority of this issue, please let
> us know.

Thank you. I don't think it is a huge priority but just wanted to get a status update.

Comment 12

[Karen Ward [:kward]]

Please provide a resolution or a date for resolution of this bug.  It has been open for 3+ months.

Comment 13

[AndyT]

I have put some pressure on the team that maintains the mobi pages. I hope this will be resolved soon.

Comment 14

[AndyT]

The page is showing exactly correct on the Firefox OS Simulator. It is extremely difficult for that team to debug if they don't have a device. Could anyone please investigate why this particular page, which is using the same template as the other Service Terms, would be rendered differently?

Comment 15

[Donovan Preston [:fzzzy]]

I will look into it.

Comment 16

[Elisa Helton]

Reproduced this on a Keon device (OS v1.1) with the new HERE Maps 2.0

Comment 17

[Donovan Preston [:fzzzy]]

I'm still investigating.

Comment 18

[Donovan Preston [:fzzzy]]

Attachment: terms.html

Example of working page, terms.html

Comment 19

[Donovan Preston [:fzzzy]]

Attachment: ads.html

Example of broken page, ads.html

Comment 20

[Donovan Preston [:fzzzy]]

I don't think we can call this a Tech Evangelism bug.

I have attached two files, terms.html and ads.html. These files are saved from the same files served by the maps app. The only difference is that I inserted newlines between dom elements to make diffing easier.

If you diff the two files, you will see that they are identical except for the content. The css stylesheet, a css reset, is identical. The structure of the dom is identical. The only difference is the text included in the two pages.

Why is this weird? Because terms.html displays fine, and ads.html is broken. If there is something Nokia can do to fix ads.html, I don't know what it is.

Another interesting data point is that the ads.html page is only broken on the phone; in the simulator, it renders just fine.

I think this is a platform bug.

Comment 21

[Elisa Helton]

Hey Donovan,
Since it's a platform bug--do you think we should redirect the bug to Jason Smith or should I create a new bug?

Comment 22

[Donovan Preston [:fzzzy]]

I'll just mark it 1.3? to see what triage for 1.3 thinks about it.

Comment 23

[Preeti Raghunath(:Preeti)]

Milan

Please review if this bug is a valid one given all the changes in panning and zooming from Graphics team.

Comment 24

[Milan Sreckovic [:milan] (needinfo for best results)]

I had trouble reproducing this, but that could have been a device.  For those that can reproduce it, does setting APZC on (from the power menu) and restarting the phone still show the problem?

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

OK, I can reproduce this with attachments. As mentioned in comment 20, terms.html and ads.html only differ by the content inside of <p> ... </p> tag. Playing with it a bit, I can get the bug to show up or not when the content differs by a single character. Content of <= 230 characters demonstrates this problem, and when we have > 230 characters, the problem goes away.

Taking ads.html and adding:
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;    
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;    
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;

to the content of the <p> tag makes the problem go away.  This content fails:

 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1\
23456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 \
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789

this content succeeds (just an extra X at the start.)

X 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1\
23456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 \
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789

-------------

David, is this somehow layout?  Or is CSS telling us exactly to behave the way we do when we have less than certain amount of text?

Comment 26

[Kartikaya Gupta (email:[e-mail])]

This is likely the result of our font inflation code. Small pieces of text don't get inflated the same way longer pieces of text do.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fundamentally, I think pages like these should be using a <meta viewport> to indicate that they don't need (and in fact don't want) a full desktop viewport that needs to be panned and zoomed around in (which is our default assumption for Web content, since there's a lot of content designed for desktop that people want to use on mobile).  People designing content like this that's designed for mobile should use <meta viewport> appropriately.  I think that's a much more appropriate fix than trying to fiddle with the font inflation heuristics more (which might be worth doing, but not for a single page).

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(I think it's worth opening a separate bug on why the simulator isn't showing the same font inflation behavior as the device... though it might be worth testing the simulator with different device widths since some of the heuristics will change as a function of device width.)

Back to tech evangelism, since stuff in preinstalled B2G apps should be using <meta viewport> rather than relying on full desktop-to-mobile conversion heuristics.

Comment 29

[Donovan Preston [:fzzzy]]

Ok, I think the <meta viewport> suggestion is a great one. Thanks a lot, David.

Comment 30

[Donovan Preston [:fzzzy]]

Pawel, can you see if the <meta viewport> suggestion helps here? (Comment 28)

If you are not the right person to look into this, can you bring it to the attention of the right person?

Thanks

Comment 31

[Pawel Wojciechowski]

Hi Donovan, thanks for your suggestion, I'll verify if this solution works fine.

Comment 32

[Nicole Fong]

What's the status?  Do we have a potential fix date?

Comment 33

[[e-mail]]

Hello all,

This issue is in our backlog but unfortunately it has been deprioritized.
Sorry for the inconvenience.

- Jussi -

Comment 34

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to [e-mail] from comment #33)
> Hello all,
> 
> This issue is in our backlog but unfortunately it has been deprioritized.
> Sorry for the inconvenience.
> 
> - Jussi -

This and other issues are affecting pre-loads on all devices in market. The carriers are keen to have these resolved.

Comment 35

[Nicole Fong]

Was unable to reproduce on ZTE V790 v1.3  Changing to Resolved - Works for me.