Bugzilla

Updated

•

11 years ago

Status: NEW → RESOLVED

Closed: 11 years ago

Resolution: --- → DUPLICATE

Comment 5

•

11 years ago

Actually this might not be a dupe.

Status: RESOLVED → REOPENED

Resolution: DUPLICATE → ---

Comment 6

•

11 years ago

Can't reproduce this. Please check again.

Keywords: qawanted

Comment 7

•

11 years ago

Weird - this only happens when applying gecko/gaia on top of the 1.2 base image. This does not reproduce when using the 1.1 base image.

blocking-b2g: --- → koi?

Component: Gaia::Browser → Gaia::System::Window Mgmt

Keywords: qawanted

Comment 8

•

11 years ago

This may be caused by bug 935219.

Preeti Raghunath(:Preeti)

Updated

•

11 years ago

blocking-b2g: koi? → koi+

Depends on: 935219

Comment 9

•

11 years ago

Botond, Are you able to reproduce this? Can you please own the bug since you seem active on the same.

blocking-b2g: koi+ → koi?

No longer depends on: 935219

Flags: needinfo?(botond)

Updated

•

11 years ago

blocking-b2g: koi? → koi+

Depends on: 935219

Comment 10

•

11 years ago

I can reproduce the issue. I'm not certain whether or not it is caused by bug 935219 - I will have to investigate.

Flags: needinfo?(botond)

Comment 11

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #10) > I can reproduce the issue. I'm not certain whether or not it is caused by > bug 935219 - I will have to investigate. I tried to reproduce this again but couldn't :( The only thing I can reproduce is when switching from landscape mode to portrait mode (with the page having initially loaded in landscape mode), the page contents only take up part of the screen horizontally. _That's_ caused by bug 935219, but I don't think 1.2 has that behaviour because it was masked by bug 937896.

Comment 12

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #11) > (In reply to Botond Ballo [:botond] from comment #10) > > I can reproduce the issue. I'm not certain whether or not it is caused by > > bug 935219 - I will have to investigate. > > I tried to reproduce this again but couldn't :( > > The only thing I can reproduce is when switching from landscape mode to > portrait mode (with the page having initially loaded in landscape mode), the > page contents only take up part of the screen horizontally. _That's_ caused > by bug 935219, but I don't think 1.2 has that behaviour because it was > masked by bug 937896. I've been playing around with this some more. I can reproduce it _very_ occasionally, usually when I turn the screen while the page is in the middle of loading. Unfortunately, I'm not able to reproduce it often enough to debug it. If anyone has any suggestions for how to reproduce this more reliably, please let me know.

Comment 13

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #12) > (In reply to Botond Ballo [:botond] from comment #11) > > (In reply to Botond Ballo [:botond] from comment #10) > > > I can reproduce the issue. I'm not certain whether or not it is caused by > > > bug 935219 - I will have to investigate. > > > > I tried to reproduce this again but couldn't :( > > > > The only thing I can reproduce is when switching from landscape mode to > > portrait mode (with the page having initially loaded in landscape mode), the > > page contents only take up part of the screen horizontally. _That's_ caused > > by bug 935219, but I don't think 1.2 has that behaviour because it was > > masked by bug 937896. > > I've been playing around with this some more. I can reproduce it _very_ > occasionally, usually when I turn the screen while the page is in the middle > of loading. Unfortunately, I'm not able to reproduce it often enough to > debug it. If anyone has any suggestions for how to reproduce this more > reliably, please let me know. I don't think you are testing this correctly. You need a 1.2 base image with gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger this bug at a high rate of reproduction.

Comment 14

•

11 years ago

(In reply to Jason Smith [:jsmith] from comment #13) > I don't think you are testing this correctly. You need a 1.2 base image with > gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger > this bug at a high rate of reproduction. I did "BRANCH=v1.2 ./config.sh hamachi" and then "./build.sh" and then "./flash.sh -f". Is there something else I should be doing?

Comment 15

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #12) > I've been playing around with this some more. I can reproduce it _very_ > occasionally, usually when I turn the screen while the page is in the middle > of loading. Unfortunately, I'm not able to reproduce it often enough to > debug it. If anyone has any suggestions for how to reproduce this more > reliably, please let me know. I managed to catch it in the debugger. It looks like the small height of the composition bounds after the orientation change comes from frameForCompositionBoundsCalculation->GetSize() at http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#684. That means the issue is unrelated to bug 935219, which has to do with how we transform frameForCompositionBoundsCalculation->GetSize() to get the final composition bounds. Here, frameForCompositionBoundsCalculation->GetSize() is wrong to begin with. Timothy, any ideas on how I can diagnose this further? Also, if anyone has more reliable STR, that would still really help, as I can still only reproduce this very occasionally.

No longer depends on: 935219

Updated

•

11 years ago

Flags: needinfo?(tnikkel)

Comment 16

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #14) > (In reply to Jason Smith [:jsmith] from comment #13) > > I don't think you are testing this correctly. You need a 1.2 base image with > > gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger > > this bug at a high rate of reproduction. > > I did "BRANCH=v1.2 ./config.sh hamachi" and then "./build.sh" and then > "./flash.sh -f". Is there something else I should be doing? The only other thing that's needed here is that base image being used here has to be a 11/15 partner 1.2 base image that you flash gaia/gecko on top of with the above commands. Do you what build was flashed on your Hamachi device from the Teleweb tool? That will tell you what base image you are running.

Comment 17

•

11 years ago

(In reply to Jason Smith [:jsmith] from comment #16) > (In reply to Botond Ballo [:botond] from comment #14) > > (In reply to Jason Smith [:jsmith] from comment #13) > > > I don't think you are testing this correctly. You need a 1.2 base image with > > > gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger > > > this bug at a high rate of reproduction. > > > > I did "BRANCH=v1.2 ./config.sh hamachi" and then "./build.sh" and then > > "./flash.sh -f". Is there something else I should be doing? > > The only other thing that's needed here is that base image being used here > has to be a 11/15 partner 1.2 base image that you flash gaia/gecko on top of > with the above commands. > > Do you what build was flashed on your Hamachi device from the Teleweb tool? > That will tell you what base image you are running. More information on what I'm referring to is here: https://intranet.mozilla.org/QA/B2G_Flash_machine#Flashing_on_TCL_Partner_Builds_.28Alcatel_One_Touch_Fire.29

Comment 18

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #15) > I managed to catch it in the debugger. It looks like the small height of the > composition bounds after the orientation change comes from > frameForCompositionBoundsCalculation->GetSize() at > http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList. > cpp#684. Is it just the case that that frame's size hasn't been updated since we changed the orientation of the device? Or it has been updated and it gets an incorrect value?

Flags: needinfo?(tnikkel)

Comment 19

•

11 years ago

(In reply to Timothy Nikkel (:tn) from comment #18) > (In reply to Botond Ballo [:botond] from comment #15) > > I managed to catch it in the debugger. It looks like the small height of the > > composition bounds after the orientation change comes from > > frameForCompositionBoundsCalculation->GetSize() at > > http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList. > > cpp#684. > > Is it just the case that that frame's size hasn't been updated since we > changed the orientation of the device? Or it has been updated and it gets an > incorrect value? The value is too small to have been correct before the orientation change, e.g. 96 pixels in height for the root apzc in the browser on a 320x480 device.

Comment 20

•

11 years ago

I would check that the calls to ResizeReflowOverride on the presshell are reasonable. If those look reasonable maybe the too small height is the result of an interrupted reflow not finishing and causing us to get a height smaller than we expect? You can check that by checking if the reflow that immediately proceeds seeing the small height in RecordFrameMetrics is interrupted by checking if interrupted at the end of PresShell::ProcessReflowCommands is true.

Comment 21

•

11 years ago

I think I've found some reliable STR for a very similar issue: 1. Open the browser in portrait mode. 2. Click on the address bar so the keyboard appears. 3. Switch to landscape mode while the keyboard is on the screen. The keyboard now occupies the bottom half of the screen in landscape mode, and we expect the browser to occupy the top half; however, the browser only occupied about the top quarter, and the homescreen background can be seen through the missing quarter. You can only see this for a fraction of the second, the browser then goes on to fill up the entire top half as expected. What I've been seeing very occasionally is the browser being stuck in that smaller state. I haven't been able to come up with STR for that, but being temporarily in that state happens reliably, and I should be able to debug that.

Comment 22

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #21) > I think I've found some reliable STR for a very similar issue: > > 1. Open the browser in portrait mode. > 2. Click on the address bar so the keyboard appears. > 3. Switch to landscape mode while the keyboard is on the screen. > > The keyboard now occupies the bottom half of the screen in landscape mode, > and we expect the browser to occupy the top half; however, the browser > only occupied about the top quarter, and the homescreen background can > be seen through the missing quarter. You can only see this for a fraction > of the second, the browser then goes on to fill up the entire top half > as expected. > > What I've been seeing very occasionally is the browser being stuck in > that smaller state. I haven't been able to come up with STR for that, > but being temporarily in that state happens reliably, and I should be > able to debug that. By the way, this happens on both 1.2 and master.

Comment 23

•

11 years ago

(In reply to Jason Smith [:jsmith] from comment #17) > (In reply to Jason Smith [:jsmith] from comment #16) > > (In reply to Botond Ballo [:botond] from comment #14) > > > (In reply to Jason Smith [:jsmith] from comment #13) > > > > I don't think you are testing this correctly. You need a 1.2 base image with > > > > gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger > > > > this bug at a high rate of reproduction. > > > > > > I did "BRANCH=v1.2 ./config.sh hamachi" and then "./build.sh" and then > > > "./flash.sh -f". Is there something else I should be doing? > > > > The only other thing that's needed here is that base image being used here > > has to be a 11/15 partner 1.2 base image that you flash gaia/gecko on top of > > with the above commands. > > > > Do you what build was flashed on your Hamachi device from the Teleweb tool? > > That will tell you what base image you are running. > > More information on what I'm referring to is here: > > https://intranet.mozilla.org/QA/ > B2G_Flash_machine#Flashing_on_TCL_Partner_Builds_.28Alcatel_One_Touch_Fire.29 I wasn't the one who initially set up the device, so I'm not sure. Is there a way to tell? Also I've done "./flash.sh -f" (note the "-f") several times since then. Would that not have overwritten whatever base image was flashed from the Teleweb tool?

Comment 24

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #23) > (In reply to Jason Smith [:jsmith] from comment #17) > > (In reply to Jason Smith [:jsmith] from comment #16) > > > (In reply to Botond Ballo [:botond] from comment #14) > > > > (In reply to Jason Smith [:jsmith] from comment #13) > > > > > I don't think you are testing this correctly. You need a 1.2 base image with > > > > > gecko/gaia on top to reproduce this. Otherwise, you won't be able to trigger > > > > > this bug at a high rate of reproduction. > > > > > > > > I did "BRANCH=v1.2 ./config.sh hamachi" and then "./build.sh" and then > > > > "./flash.sh -f". Is there something else I should be doing? > > > > > > The only other thing that's needed here is that base image being used here > > > has to be a 11/15 partner 1.2 base image that you flash gaia/gecko on top of > > > with the above commands. > > > > > > Do you what build was flashed on your Hamachi device from the Teleweb tool? > > > That will tell you what base image you are running. > > > > More information on what I'm referring to is here: > > > > https://intranet.mozilla.org/QA/ > > B2G_Flash_machine#Flashing_on_TCL_Partner_Builds_.28Alcatel_One_Touch_Fire.29 > > I wasn't the one who initially set up the device, so I'm not sure. Is there > a way to tell? Naoki I believe had a way to detect this on device. I'll needinfo him for input on that. > > Also I've done "./flash.sh -f" (note the "-f") several times since then. > Would that not have overwritten whatever base image was flashed from the > Teleweb tool? I'm going to wait for Naoki to weigh in on this. He'll be able to give you the details on this.

Flags: needinfo?(nhirata.bugzilla)

Comment 25

•

11 years ago

Another thing to do would be to get a frame dump of the whole document when we have the too small in height frame. That will tell us if its the whole document thats too small or just that frame.

Comment 28

•

11 years ago

Attached file bug941745-frame-dump.txt — Details

(In reply to Timothy Nikkel (:tn) from comment #25) > Another thing to do would be to get a frame dump of the whole document when > we have the too small in height frame. Attached is an frame dump. The scrollable frame whose composition bounds are smaller than expected is the HTMLScroll on the second line. Notes: - This is on a Nexus 4 device. The screen size is 768x1280, and the app unit to device pixel scale is 30. - At the time of this frame dump, the device was in portrait orientation. - The frame dump is for the content document shown in the browser. I would expect this document to take up all of the screen height (minus the chrome) but it's only about half the height of the screen at 558 pixels. > That will tell us if its the whole document thats too small or just that frame. Since this is the root frame of the document, I guess the whole document is too small?

Comment 29

•

11 years ago

(In reply to Timothy Nikkel (:tn) from comment #20) > I would check that the calls to ResizeReflowOverride on the presshell are > reasonable. > > If those look reasonable maybe the too small height is the result of an > interrupted reflow not finishing and causing us to get a height smaller than > we expect? You can check that by checking if the reflow that immediately > proceeds seeing the small height in RecordFrameMetrics is interrupted by > checking if interrupted at the end of PresShell::ProcessReflowCommands is > true. ResizeReflowOverride is being called with the incorrect height. This in turn comes from TabChild::SetViewport(). It looks like TabChild::mInnerSize.height is incorrect.

Assignee

Updated

•

11 years ago

Assignee: nobody → gchen

Comment 30

•

11 years ago

(In reply to Botond Ballo [:botond] from comment #29) > (In reply to Timothy Nikkel (:tn) from comment #20) > > I would check that the calls to ResizeReflowOverride on the presshell are > > reasonable. > > > > If those look reasonable maybe the too small height is the result of an > > interrupted reflow not finishing and causing us to get a height smaller than > > we expect? You can check that by checking if the reflow that immediately > > proceeds seeing the small height in RecordFrameMetrics is interrupted by > > checking if interrupted at the end of PresShell::ProcessReflowCommands is > > true. > > ResizeReflowOverride is being called with the incorrect height. This in turn > comes from TabChild::SetViewport(). It looks like > TabChild::mInnerSize.height is incorrect. In turn, that's being set by a resize reflow of the document in the parent process. The debugger only shows me the immediate caller of that, which is nsViewManager::SetWindowDimensions, it doesn't show the rest of the stack trace.

Comment 31

•

11 years ago

There aren't too many callers of that, maybe you can get the callers with printf help or breaking on the callers and then get a stack. Maybe it's a delayed resize on the view manager and it's racing with something?

Assignee

Comment 32

•

11 years ago

This is keybaord manager issue and already have a patch. https://github.com/mozilla-b2g/gaia/pull/14227 This patch is for bug 941567. I've tried and tested, it can fix this issue.

Flags: needinfo?(nhirata.bugzilla)

Alex Keybl [:akeybl]

Comment 33

•

11 years ago

We took bug 941567, given comment 32's assertion that it resolves this bug.

Comment 34

•

11 years ago

Fixed via landing of bug 941567.

Status: REOPENED → RESOLVED

Closed: 11 years ago → 11 years ago

Component: Gaia::System::Window Mgmt → Gaia::System

Depends on: 941567

Resolution: --- → FIXED

Assignee

Comment 35

•

11 years ago

Hi all, Bug 941567 has landed in master and v1.2, please verify this issue again. Thanks. see also bug 944578#c0, tap browser address bar bar and let keyboard appear is necessary. Can not reproduce on this build. v1.2 Gaia: bcb83d1e19ede0b993ceaabc8017f8c4163594e9 master Gaia: 4fd13a4f6a99bfc51f0ec7ab462e7390e36e27d1

Ryan VanderMeulen [:RyanVM]

Updated

•

11 years ago

Keywords: verifyme

Updated

•

11 years ago

status-b2g-v1.2: --- → fixed

Josh Schmitt [Joshs]

Comment 36

•

11 years ago

The issue does not repo in latest Buri v1.2 build, however the issue still occurs in the latest Master build v1.3. The Browser renders incorrectly in when switching to landscape mode, Bug 944578 does not occur. Master: Environmental Variables Device: Buri v1.3 Moz Ril Build ID: 20131203040236 Gecko: 8648aa476eef Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b Platform Version: 28.0a1 RIL Version: 01.02.00.019.102 Firmware Version: v1.2_20131115 Buri v1.2: Environmental Variables Device: Buri v1.2 COM RIL Build ID: 20131203004002 Gecko: 244e98241b2c Gaia: c8f14ad3950d59ba13d7639eff02d080060bb3ce Platform Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: v1.2_20131115

Josh Schmitt [Joshs]

Updated

•

11 years ago

status-b2g-v1.2: fixed → verified