Closed Bug 511432 Opened 11 years ago Closed 10 years ago
Handle panning inside overflow:auto elements (Google Reader)
I'm trying to create a minimized test case, but it's proving to be quite difficult due to the amount of JS associated style on reader.google.com. Here are the steps: 1. Log into reader.google.com 2. Click a summarized post to load it into the "viewer" construct (this is a div that lives inside a table with the background-attachment: scroll style property set) 3. You can't scroll the view container. You can do this on 1.9.2 and m-c Firefox builds, but not on Fennec. = Expected = You can scroll the view container without scrolling the entire page = Actual = Scrolling pans the entire page, and you can't scroll the "current" blog post so you have no way to read that post without going to the explicit blog site. Which pretty much makes google reader completely broken on fennec. Hopefully I can find a way to get a minimized testcase for this.
I don't know if the pattern used on reader.google.com is used much on the web in general, but if it is, then this should block fennec. We may not be able to make that assessment until we have a minimized test case, but I'll get it in the triage stack anyway. Noming for blocking.
tracking-fennec: --- → ?
could be similar to the iframe issue in bug 458741
It seems like none of the overflow:scroll divs are scrollable at all in Fennec, as this testcase indicates.
Btw, I would really want some kind of UI that indicates the overflow:scroll div is in fact scrollable.
Yeah, this is similar to the iframe issue, and probably could be solved using the same code. Right now, we explicitly look for iframe/frame elements, we'd have to expand that search to also handle overflow:scroll marked element. Urgh!
Summary: Google Reader doesn't scroll the "current" entry on Fennec → Handle panning inside overflow:auto elements (Google Reader)
Also test url http://kentbrewster.com/identica-badge/ which uses overflow-x and overflow-y attributes.
I chatted on #developers about this... I feel that we may need a faster search to find the "scrollable element that's a parent of a particular element", something in DOMUtils. This would find the first element in the parent list that you can adjust via scrolling, either due to being FRAME/IFRAME or having the right CSS attribute or being the final document.
We were only testing overflow with the "overflow" CSS property, but not "overflow-x" and "overflow-y". Google Reader uses "overflow-x" for instance.
Assignee: combee → fabrice.desre
Attachment #415602 - Flags: review?(mark.finkle)
Attachment #415602 - Flags: review?(mark.finkle) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Post-B5
verified FIXED using testcase on builds: Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091203 Firefox/3.6b5pre Fennec/1.0b6pre and Mozilla/5.0 (X11; U; Linux armv6l; Nokia N8xx; en-US; rv:1.9.3a1pre) Gecko/20091203 Firefox/3.7a1pre Fennec/1.0b5
Status: RESOLVED → VERIFIED
litmus testcase: https://litmus.mozilla.org/show_test.cgi?id=11559 has been created to regression test this bug.
Flags: in-litmus? → in-litmus+
I still have problems on Google Reader reading some of the posts. A good example I have spotted is the feed from David Tenser (http://djst.org/blog/feed/). Add it to Google Reader and try to read the post about "Random UX change for the sake of... change?" which extends the normal space. You will see some cut-off letters at the bottom of the frame but no scrolling is possible. You are even not able to scroll further down to get to the next postings. Does it mean this bug is not fixed yet or shall I file that as a new bug?
Filed as bug 556414.
Component: Linux/Maemo → General
OS: Linux → Linux (embedded)
QA Contact: maemo-linux → general
You need to log in before you can comment on or make changes to this bug.