Closed
Bug 830256
Opened 12 years ago
Closed 12 years ago
The content becomes white after keyboard down from bookmark of homescreen.
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed, b2g18-v1.0.0 fixed)
People
(Reporter: askeing, Assigned: jrmuizel)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
ajones
:
review+
|
Details | Diff | Splinter Review |
Device: Unagi Build Identifier: 20130113070202 ## Repro : 1. launch browser 2. go to http://www.soso.com 3. select the star -> add to homescreen 4. hit home 5. select the new icon 6. tap on white area to make keyborad comes down. ## Expected : 1. keyboard will comes down and you still can see the content. ## Actual : 1. after the keyboard comes down, the content area is completely white; scrolling can show the content. Youtube: http://www.youtube.com/watch?v=b-25bNnvH5o
Updated•12 years ago
|
blocking-b2g: --- → tef?
tracking-b2g18:
--- → ?
Updated•12 years ago
|
Assignee | ||
Comment 4•12 years ago
|
||
This seems to happen for any input box: http://people.mozilla.org/~jmuizelaar/bugs/text.html
Assignee | ||
Comment 6•12 years ago
|
||
Broken/White: OGLShadowContainerLayer (0x117c580a8) [shadow-visible=< (x=0, y=142, w=320, h=223); >] [visible=< (x=0, y=142, w=320, h=223); >] [opaqueContent] [metrics={ viewport=(x=0.000000, y=0.000000, w=320.000000, h=365.000000) viewportScroll=(x=0.000000, y=0.000000) displayport=(x=0.000000, y=142.000000, w=320.000000, h=223.000000) scrollId=1 }] OGLShadowThebesLayer (0x117c58ca8) [shadow-visible=< (x=0, y=142, w=320, h=223); >] [visible=< (x=0, y=142, w=320, h=223); >] [opaqueContent] [valid=< (x=0, y=142, w=320, h=223); >] Fixed: OGLShadowContainerLayer (0x117c580a8) [shadow-visible=< (x=0, y=0, w=320, h=365); >] [visible=< (x=0, y=0, w=320, h=365); >] [opaqueContent] [metrics={ viewport=(x=0.000000, y=0.000000, w=320.000000, h=365.000000) viewportScroll=(x=0.000000, y=0.000000) displayport=(x=0.000000, y=0.000000, w=320.000000, h=365.000000) scrollId=1 }] OGLShadowThebesLayer (0x117c58ca8) [shadow-visible=< (x=0, y=0, w=320, h=365); >] [visible=< (x=0, y=0, w=320, h=365); >] [opaqueContent] [valid=< (x=0, y=0, w=320, h=365); >] The visible area for the content layer is wrong.
Assignee | ||
Comment 8•12 years ago
|
||
We have an mScrollableRect with a height of 223 and we sort of clamp the display port to that. The problem is that the code expects mScrollableRect to be larger than than the compositionRect, but when the page is resized when the keyboard is up the scrollableRect will shrink to the new size.
Assignee: nobody → matt.woodrow
Assignee | ||
Updated•12 years ago
|
Assignee: matt.woodrow → jmuizelaar
Assignee | ||
Comment 9•12 years ago
|
||
Ensure that scrollable rect as at least as big as the drawable area. Otherwise we end up clamping the displayport to a smaller size than we should be.
Assignee | ||
Updated•12 years ago
|
Attachment #702107 -
Flags: review?(ajones)
Assignee | ||
Updated•12 years ago
|
Attachment #702107 -
Flags: review?(jones.chris.g)
Comment on attachment 702107 [details] [diff] [review] Ensure that scrollable rect as at least as big as the drawable area This patch doesn't quite make sense to me. 1. Where is the bad scrollableRect value coming from? 2. If this happens, why would we think a priori we need to shift content left/up instead of right/down?
Attachment #702107 -
Flags: review?(jones.chris.g)
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #10) > Comment on attachment 702107 [details] [diff] [review] > Ensure that scrollable rect as at least as big as the drawable area > > This patch doesn't quite make sense to me. > 1. Where is the bad scrollableRect value coming from? The bad scroll rect comes from having resized the content area to make room for the keyboard. i.e. if the actual height of the page is shorter than the content area the scrollableRect will only be as large as the content area. When the keyboard goes away we still have the previous scrollable rect because the page has not yet changed size to fill up the new space. > 2. If this happens, why would we think a priori we need to shift content > left/up instead of right/down? This was an arbitrary choice. The only important part for this patch is that the scrollable rect be at least as large and not start before 0,0.
Updated•12 years ago
|
blocking-b2g: tef? → -
Comment on attachment 702107 [details] [diff] [review] Ensure that scrollable rect as at least as big as the drawable area This patch makes me very uncomfortable because it feels like we're papering over a more fundamental problem, but this is a pretty serious bug and maybe the best we can do at this point.
Attachment #702107 -
Flags: review+
Assignee | ||
Comment 13•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12) > Comment on attachment 702107 [details] [diff] [review] > Ensure that scrollable rect as at least as big as the drawable area > > This patch makes me very uncomfortable because it feels like we're papering > over a more fundamental problem, but this is a pretty serious bug and maybe > the best we can do at this point. I guess the fundamental problem is that the scrollableRect depends on the size of the displayport/viewport and we don't get the new scrollableRect until after the TabChild has changed size. What kind of solution would you suggest?
I don't understand why gecko isn't reflowing out to the widget dimensions. I also don't understand why content was trying to repaint at the ~y offset of the keyboard (I think, per comment 6) instead of y=0.
Assignee | ||
Comment 15•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14) > I don't understand why gecko isn't reflowing out to the widget dimensions. We intersect the displayport with the scrollableRect which is smaller than the widget dimensions. Presumably, the smaller displayport dimensions override the widget dimensions. > I also don't understand why content was trying to repaint at the ~y offset > of the keyboard (I think, per comment 6) instead of y=0. This happens because we adjust the scrollOffset.y to compositionBounds.width - scrollableRect.width, which is a negative value. We then translate by -scrollOffset.y intersect with the scrollableRect and translate by scrollOffset.y. This moves the displayport to half way down the page.
Comment 16•12 years ago
|
||
Comment on attachment 702107 [details] [diff] [review] Ensure that scrollable rect as at least as big as the drawable area Review of attachment 702107 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/AsyncPanZoomController.cpp @@ +842,5 @@ > + // Ensure the scrollableRect is at least as big as the compositionBounds > + // because the scrollableRect can be smaller if the content is not large > + if (scrollableRect.width < compositionBounds.width) { > + scrollableRect.x = NS_MAX(0.f, > + scrollableRect.x - compositionBounds.width - scrollableRect.width); Should be brackets around (compositionBounds.width - scrollableRect.width)
Attachment #702107 -
Flags: review?(ajones) → review-
Assignee | ||
Comment 17•12 years ago
|
||
Attachment #702107 -
Attachment is obsolete: true
Attachment #703044 -
Flags: review?
Updated•12 years ago
|
Attachment #703044 -
Flags: review? → review+
Assignee | ||
Comment 18•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/339344803492
Comment 19•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/339344803492
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 21•12 years ago
|
||
TEF+ Bug 832222 was marked as duplicate of this bug, so this bug should be TEF+ and we should uplift this patch to b2g18's branches.
blocking-b2g: - → tef?
Updated•12 years ago
|
blocking-b2g: tef? → tef+
status-b2g18:
--- → affected
status-b2g18-v1.0.0:
--- → affected
tracking-b2g18:
+ → ---
Comment 22•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g18/rev/1e1ed4598a7f https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0/rev/785cac703746
status-firefox19:
--- → wontfix
status-firefox20:
--- → wontfix
status-firefox21:
--- → fixed
Target Milestone: --- → B2G C4 (2jan on)
Comment 23•12 years ago
|
||
Verified issue fixed on Unagi Build ID 20130214070203 Kernel Dec 5 Gecko:http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/d1288313218e Gaia: 6544fdb8dddc56f1aefe94482402488c89eeec49
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•