803878 - HTML5 with javascript slides a total mess

Status: NEW

(Core :: Layout, defect)

Description

[Dario Bertero]

Attachment: Page source retrieved from the site

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121012050625

Steps to reproduce:

Viewed this website on Asus Transformer TF101, running Android 4.0.3: http://mozilla.bonardo.net/torino2012/
Got different results (but both unsatisfactory) on 16.0.1 stable version and on 2012.10.20 nightly relase (the latter is faster).


Actual results:

The presentation is a total mess, hard to be read and to be navigated, especially when animations are showed. It slows down the device (much more using the stable relase).


Expected results:

Presentation running smoothly.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Does setting 'Text size' in the Firefox Settings to tiny or press the small A till the button is disabled and reloading the page have any affect?

Comment 2

[Dario Bertero]

Nothing changes.

Comment 3

[Aaron Train [:aaronmt]]

Noting that the presentation is using DZSlides. Are you able to reproduce with any of Paul's presentations here: http://paulrouget.com/dzslides/?

Kats, can you take a look at this?

Comment 4

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

Attachment: Screenshot

Can you describe in more detail what you're seeing? I see things like the attached screenshot when I navigate through the slideshow. This appears to be invalidation problems and possibly related to DLBI. I didn't see this behaviour on Beta (17), although there I did some cropping on the tops of the slide titles. I'm testing on a Galaxy Nexus.

Comment 5

[Dario Bertero]

I have a very similar behaviour, sometimes with residual images in different places, and it is much worse in the stable version than in the last nightly. In addition, related to both versions, the transitions are not smooth at all, and when the device is rotated the presentation is not centered anymore and very hard to navigate, even if put back to the original position (only refreshing the page restores the original situation). 
With Paul Roget presentation I get again the same problems.

Comment 6

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

Ok, I see similar behaviour. The behaviour on rotation is definitely pretty bad. I can take a look at that.

Blocking dlbi and CC'ing matt woodrow for the invalidation issues.

Comment 7

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

My initial attempts at debugging the rotation problem kept running into bug 799530 so I investigated that some. I'll see if I can hack in a workaround to avoid hitting that bug and dig a little deeper into the rotation issue.

Comment 8

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

Attachment: Logcat with debug logging

The wonkiness on rotation (specifically that the page gets elongated vertically such that the title of the slide ends up at the bottom of the visible area) also sometimes happen on first load of the page. I was able to reproduce it at least 50% of the time, and I added logging to try to trace what was going on. Attached is a logcat with my log output that covers (1) starting fennec and (2) clicking on the top sites thumbnail for http://mozilla.bonardo.net/torino2012/.

In the log, I click on the thumbnail at timestamp 18:05:01.884, and the page starts loading. The first event we receive in browser.js is a MozScrolledAreaChanged at 18:05:02.235. At that point the document body's scroll dimensions are 0x0 and the html element's scroll dimensions are 720x1038.

The next event we receive in browser.js is another MozScrolledAreaChanged at 18:05:02.650. Now the body's scroll dimensions has expanded to 2000x1124. I don't understand why the body is 2000 pixels wide, but this is what causes the page to be elongated. Because the body is 2000 pixels wide, we have to size the CSS viewport to be extra-tall so that even when the user zooms out all the way (such that the 2000 CSS pixels of width is visible in the 720 device pixels) the page is tall enough to cover the visible area. (The logic responsible for doing this is in updateViewportSize(), look for "minScale".) Because of this 2000-pixel wide document, we size the CSS viewport to be 980x2883.3333333333335 (at 18:05:02.939 in the log) and that's why the page renders as super-tall.

On the instances where this doesn't happen on the first load of the page, it will still happen reliably on rotation, and for the same reason. That is, upon rotating the device, the page width suddenly ends up as 2000 CSS pixels, and so we have to adjust the CSS viewport to accomodate this.

I have absolutely no idea where the 2000 pixel width is coming from - the page at http://mozilla.bonardo.net/torino2012/ doesn't have it hard-coded anywhere, and it looks like it should always be 800 pixels wide multipled by some scale so that it fits snugly into the CSS viewport. Also note that before I click on the thumbnail to load the page, the CSS viewport is set to 980x1412.8333333333333 while we are on the about:home page, so it's not like we've got an undefined CSS viewport to start with. I can only assume that the 2000 is used as some default "magic constant" type number somewhere in layout.

Comment 9

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

Attachment: Patch to add debug logging

This is the patch that contains the debug logging I added to generate the trace in attachment 677580 [details]. It also contains a hacky workaround for the issue in bug 799530 (the hacky workaround is the block of code commented out in PanZoomController.java).

Comment 10

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

Attachment: Screenshot of elongated page

Also for completeness this is what the bad behaviour I was investigating looks like. The page is too tall, and so the slide content is shifted so far down that only the top of the slide appears on screen. This behaviour can be observed either right when the page is loaded, or after rotating back and forth.

Comment 11

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

Moving over to Core:Layout based on my investigation in comment 8. The invalidation issue pointed out in comment 4 is also probably a layout issue anyway (although maybe it's worth splitting this into two bugs for the two issues).

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Per comment #5 this doesn't sound like DLBI. Although it's a pretty bad bug we should fix!