813841 - [email] Explicitly sized HTML Body content appears to scroll under message envelope

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

When scrolling down (swipe up) in an e-mail message, the body of the message scrolls under the header (subject, to/from) content. This is awkward and prevents a clean view of the body content.

STR
1. Open an e-mail message
2. Scroll down

Expected: The body of the e-mail is locked to the header content and scrolls as one.

Actual:
The body of the e-mail scrolls up under the header content, which also scrolls.

Stable build 2012-11-14 09:49:28
Unagi
GMail

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

We already should reliably do what you request for messages where we can display the contents seamlessly, such as text/plain and text/html messages that do not have a fixed width.  We display HTML messages that evidence a desire to be wider in an iframe with pinch-to-zoom functionality.

What I suspect you are experiencing is the panning inside the iframe.  We are severely limited by what the platform provides us with (no seamless iframes, no native pinch/zoom), so we use the logic in
  https://github.com/mozilla-b2g/gaia/blob/master/apps/email/js/iframe-shims.js
to try and approximate something useful.  It probably could still use a lot of love!

I suspect what is happening is that the iframe's scrolling is eating the input events to service its own internal scrolling and potentially never letting the page's own scrolling happen.  Since the attachments list now shows up before the body proper, what we likely want to do is to have our iframe input processing only scroll down once the page has scrolled all the way down.  In the opposite direction, we should not let the page scroll up until the iframe has scrolled all the way up.  (Note: we would still behave oddly if the scrolling happens on the header rather than over part of our iframe without even more logic...)

Alternatively, instead of having a screen-sized viewport, we could do a manual seamless thing where we resize our iframe based on pinch-to-zoom scaling and provide for horizontal panning, but try and leave all vertical motion to the browser.


Steve, I'm copying you on this mainly so that if you have spare cycles you can maybe play around with this a little and see if you can make improvements.  I'm requesting blocking-basecamp so that drivers can try and prioritize this if they think it's important.

Comment 2

[Lawrence Mandel [:lmandel] (use needinfo)]

To be clear, the header does scroll as does the body content. The body content scrolls more quickly than the page content and therefore moves under the header content.

Here is a link to a video that may help clarify what I'm experiencing. Notice how the e-mail header does scroll up as does the body content. Also notice the "Blacks" masthead scroll under the e-mail header content.
https://www.youtube.com/watch?v=FuXCLbcAPCA

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Thanks very much for providing the video!

We are talking about the same thing; all kinds of b2g builds are busted for me today so I was going from hazy memory.  What you are seeing is more consistent with the code than what I was describing, so that makes sense.  (There may have also been changes in platform behaviour or I think we removed a pointer-events: none that could also have some impacted things.)

Either way, it's our nested iframe and our event handling related to that which causes the cool scrolling behaviour.

Comment 4

[Steve Chung [:steveck]]

Hi all,
After some testing(using 11/20 RD code base), I could not reproduce the issue that part of content was scrolled under the header. Instead, I discover another interesting issue. When scrolling the HTML content, header position was fixed and only the content of iframe was scrolled. But if you scroll the header, whole message read view was scrolled. If the header scrolls over the screen top, there is no way to scroll the header back to original position because panning inside the iframe could only scroll the HTML content. You could only scroll to the top of the HTML content. The only way to traverse whole message read view at that moment is using the slide bar at the right hand side of page.

Hi Andrew,
It looks like some logic in iframe-shims.js might have some problem when scrolling up while header is visible (page should be scrolled up instead of content) and scrolling down while header is invisible and content at top (page should be scrolled down). It seems second method is also a candidate because it reduce the logic to control the page position(but we need to control the frame size while zoom in/out and horizontal scrolling...). Is there any reason (like animation performance while zooming) that make you choose fixed-size viewport as the current layout? Thanks.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Short answer: easiest solution available for a first implementation, knew we'd want to follow-up and spend more time later.  Since newsletter mode has HTML content wider than the screen, it implied some type of pinch/zoom interface.  Gallery already had code for that and worked with a fixed viewport.  I did think about performance somewhat, but didn't have enough information about how our implementation works to be able to confidently do anything for that other than knowing that we want to use 'transform'.  I assume our scaling transform is probably bad from a performance and resources perspective, although maybe we luck out somehow.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

Steve, assigning this to you for now since you've already started investigating.  I think there are a bunch of contractors showing up, so if you're busy, we can probably find someone to look at it.

Comment 7

[Steve Chung [:steveck]]

No problem, I just forgot to take it.

Comment 8

[Steve Chung [:steveck]]

Attachment: Patch for fixing HTML message layout

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 685133 [details]
Patch for fixing HTML message layout

Review performed on github; please re-request with next revision of the patch.

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

We have landed my attempt at a less-viewporty more-seamless as a preliminary fix on gaia/master:
https://github.com/mozilla-b2g/gaia/pull/6676

There is still a bit to do in terms of the zooming logic, discarding the obsolete logic, and link-click-handling (bug 814442) which is fairly initimately related to this bug because it causes us to need to disable pointer-events and use document.elementFromPoint or something else instead (probably scaled).  schung is currently working these, and so I've also assigned linkification to him for now as well.

Comment 12

[Steve Chung [:steveck]]

Attachment: Patch for mail size update after image loaded and zoom gesture fixing

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 685133 [details]
Patch for fixing HTML message layout

(obsoleting the mooted pull request)

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 686988 [details]
Patch for mail size update after image loaded and zoom gesture fixing

Comments provided on pull request; please re-request review for next rev of the patch.  Please attach a separate pull request for the gaia-email-libs-and-more changes too.  Thanks!

Comment 15

[Steve Chung [:steveck]]

Attachment: Patch for mail api changes

Comment 16

[Nick Davidson]

HTML Body content now scrolls together  with message envelope verified on Unagi build 20121231070201

Comment 17

[Nick Davidson]

Also verified on Unagi build 20130103070201