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%

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?

(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.

Version number is 1.8.44

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

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

what is the status of this bug?

I was able to reproduce this on build 18.1 20130921041201. Pawel, any update on this getting fixed?

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

(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.

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

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

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?

I will look into it.

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

I'm still investigating.

Example of working page, terms.html

Example of broken page, ads.html

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.

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?

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

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

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?

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?

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.

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).

(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.

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

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

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

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

Hello all, This issue is in our backlog but unfortunately it has been deprioritized. Sorry for the inconvenience. - Jussi -

(In reply to jussi.ar.silfver@here.com 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.

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