Closed Bug 825622 Opened 12 years ago Closed 7 years ago

Tapping settings app UI while "Open Source Notice" is loading causes all-white window to be rendered after notice loads

Categories

(Firefox OS Graveyard :: General, defect, P2)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:-)

Status:
RESOLVED WONTFIX
Milestone:
B2G C4 (2jan on)
Project Flags:
blocking-basecamp -

People

(Reporter: nbp, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: b2g-testdriver) 

STR:
 (can reproduce with: en-US, fr, pt-BR)
 - Tap Settings
 - Tap Device Information
 - Tap Legal information
 - Tap Open Source Notice

Seen:
 - Nothing happen, and a white screen show up after a short while.

Expected:
 - Start the browser app.

Logcat:
E/GeckoConsole( 2026): [JavaScript Warning: "The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it." {file: "app://settings.gaiamobile.org/resources/open_source_license.html" line: 0}]

Device info:
 - OS: 1.0.0
 - Hardware: nice
 - Platform: 18.0
 - Build id: 20121226070202
 - Channel: beta
 - Git info: 2012-12-26 15:10:59  (unknown sha1)
Not able to repro using the 20121231 nightly unagi build.
(In reply to Marcia Knous [:marcia] from comment #1)
> Not able to repro using the 20121231 nightly unagi build.

I was able to reproduce it with Vivien's phone today, can you give the sha1 on which you are based on?
Triage: BB+, P2, C4 - reproduced on 01/01 & 01/02 build
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C4 (2jan on)
Assignee: nobody → rexboy
It's not reproducing reliably for me. But often enough.

logcat:
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:532480 offset:1802240 fd:88
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x45800000 size:2334720 offset:1802240 fd:41
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:532480 offset:2334720 fd:96
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x45acd000 size:2867200 offset:2334720 fd:44
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:532480 offset:5087232 fd:100
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x469cc000 size:5619712 offset:5087232 fd:47
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:8192 offset:81920 fd:103
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x42434000 size:90112 offset:81920 fd:50
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:81920 offset:90112 fd:106
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x42800000 size:172032 offset:90112 fd:65
D/memalloc( 1673): /dev/pmem: Allocated buffer base:0x49d5a000 size:114688 offset:327680 fd:112
D/memalloc( 2186): /dev/pmem: Mapped buffer base:0x42847000 size:442368 offset:327680 fd:68
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x4a016000 size:532480 offset:2867200 fd:123
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x44d0a000 size:3399680 offset:2867200
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x4667a000 size:3481600 offset:3399680
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x4a338000 size:532480 offset:6152192 fd:145
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x4a098000 size:81920 offset:3399680 fd:148
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49d96000 size:81920 offset:245760 fd:136
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x45f3a000 size:6684672 offset:6152192
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x424a8000 size:327680 offset:245760
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49f12000 size:532480 offset:1802240 fd:88
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49f94000 size:532480 offset:2334720 fd:96
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x4a234000 size:532480 offset:5087232 fd:100
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49d6e000 size:8192 offset:81920 fd:103
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49d70000 size:81920 offset:90112 fd:106
D/memalloc( 1673): /dev/pmem: Freeing buffer base:0x49daa000 size:114688 offset:327680 fd:112
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x45800000 size:2334720 offset:1802240
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x45acd000 size:2867200 offset:2334720
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x469cc000 size:5619712 offset:5087232
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x42434000 size:90112 offset:81920
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x42800000 size:172032 offset:90112
D/memalloc( 2186): /dev/pmem: Unmapping buffer base:0x42847000 size:442368 offset:327680
Do we expect the license show in the browser app?  It is shown inside a setting app panel before.  Actually it's an local side html document laid in an iframe, which costs 10 secs or longer to load (by lazy loading) and thus made UI unresponsive before loading is done.  We may do something to improve the response time.
Not sure why the white screen come out... the license panel do show up but seems like it's soon covered by a white panel.  The logcat warning is not the main reason.  Still digging.
I have a WIP patch that removes the setTimeout() calls in showPanel(). That seems to solve this bug but I'm still testing because some panel transitions are not as good as before.
I found it may be a repainting problem inside Gecko, because the back button on the left top is still tappable while the screen is completely white.  The Open Source Notice page is just **too long** for Unagi -- I need almost a second scrolling speedily to reach the bottom!  The extremely long page costs too much time to load and may be the culprit of the repainting problem.  I suggest doing some paging by each license (and 2~3 pages for permissive license) and the problem may gone automatically.
rexboy> what would happen when the user meet real long pages on Internet that we don't control ?
Julien:
I'd like to correct my opinion.  I tried to shorten Open Source Notice page.  Although the bug still exists, I found the STR 100% reproducible it for me:
 - Tap Settings
 - Tap Device Information
 - Tap Legal information
 - Tap Open Source Notice
 - While loading, tap anywhere once on the screen.

Expected:
 - Open Source Notice page shown.

Actual:
 - A white page comes up.  Back button can't be seen but it's still functioning.

Not sure whether it's a regression.  It's not reproducible on gecko 20 of 12/10.
Chris, need some help here, see comment 7 - 9. Looks like a b2g18 specific rendering issue.
Assignee: rexboy → nobody
Component: Gaia::Settings → General
Flags: needinfo?(jones.chris.g)
Milan, can you find an owner for this apparent rendering issue?
Assignee: nobody → milan
rexboy: I believe this is just a bad behaviour on Gaia. If I set the background to red, it turns into a red screen. So I believe we're just hidding the page once it's loaded with some race condition.
The back button is completely unresponsive while this page loads, so it appears that we're loading and reflowing everything in one event-loop iteration.  That's taking at least 10sec or so.  Surprising that interruptible reflow isn't kicking in.

As for the white content, my best guess is that the tap event is causing a new focus that's doing a bogus scroll-focused-content-into-view, but no ideas beyond that.
Flags: needinfo?(jones.chris.g)
Keywords: crash
Discard comment 12, I was mistaken.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #13)
> The back button is completely unresponsive while this page loads, so it
> appears that we're loading and reflowing everything in one event-loop
> iteration.  That's taking at least 10sec or so.  Surprising that
> interruptible reflow isn't kicking in.
> 

Should we workaround this in Gaia or we need to look for platform fix?

> As for the white content, my best guess is that the tap event is causing a
> new focus that's doing a bogus scroll-focused-content-into-view, but no
> ideas beyond that.

Yes, I think you are right about this.
Flags: needinfo?(jones.chris.g)
I can confirm that convert all the text into comments "fix" this issue.
Let's see if we can find a platform person to take a look at the underlying bug.
Flags: needinfo?(jones.chris.g)
> Surprising that interruptible reflow isn't kicking in.

There is no interruptible reflow on B2G, afaict.  Interrupts only happen if HasPendingInputEvent() on the nearest nsIWidget returns true, and I don't see either PuppetWidget or the gonk version of nsWindow ever doing that.

Still reading the rest of the bug...
OK, read the rest of it now.  Is the issue we're worried on platform side the lack of interruptible reflow, the fact that rendering about:license (I assume that's what we're rendering here) takes a while, or something else?

I can suggest workarounds that involve changing about:license to be less one-shot if that's what it takes.  But that's only 150KB of text or so, without any serious CSS insanity; it really shouldn't be taking 10s to render....
(In reply to Boris Zbarsky (:bz) from comment #18)
> > Surprising that interruptible reflow isn't kicking in.
> 
> There is no interruptible reflow on B2G, afaict.  Interrupts only happen if
> HasPendingInputEvent() on the nearest nsIWidget returns true, and I don't
> see either PuppetWidget or the gonk version of nsWindow ever doing that.

Ah ok, that makes sense.  It's a bit nontrivial for us to do that in PuppetWidget but it's possible.
(In reply to Boris Zbarsky (:bz) from comment #19)
> OK, read the rest of it now.  Is the issue we're worried on platform side
> the lack of interruptible reflow, the fact that rendering about:license (I
> assume that's what we're rendering here) takes a while, or something else?

The problem this bug covers is that tapping anywhere in the settings app while the license text is loading causes the entire settings-app window to render white once the text loads.
Still on the reflow interrupt thing, we could also switch to one of the other interrupt modes (e.g. the one that interrupts deterministically off a counter once 100ms have passed).  But if we can hook up HasPendingInputEvent that would be _way_ better.
Absolutely.
Summary: Open Source Notice cause the setting app to crash. → Tapping settings app UI while "Open Source Notice" is loading causes all-white window to be rendered after notice loads
Benoit, let's keep this one going through the time difference.
Assignee: milan → bjacob
Whiteboard: [b2g-gfx]
Here's a profile, confirming that we're spending this time reflowing:

http://people.mozilla.com/~bgirard/cleopatra/#report=3b565949e20bf7d965adaaf95e8e8fc5c91efde3

There doesn't seem to be a crash here (which I also assume is why this bug just got renamed accordingly), just slow layout work. I'd like to help more, but realistically, a layout person would be more efficient than me at this.
The previous profile had bad symbols, apparently because profiling on B2G does not work unless one has --disable-elf-hack. (Working to confirm that theory). Here is a profile obtained with a --disable-elf-hack build, which looks much better:

http://people.mozilla.com/~bgirard/cleopatra/#report=75848aa8ceae25cbd7e49ba1518793cdcc2156bb
The other thing to do here is add more SAMPLE_LABEL's around DoReflow to get better profiles. Currently we know we spend 80% time there, and we know a list of functions below there where we spend time, but we don't have a good tree view.
Looks like your typical flat-ish layout profile.  The stuff near the top all has to do with text layout, which is not surprising: there's not much more than text involved here.
But, surely it's not considered OK that we take about 10 seconds to reflow this page. Text layout is not my forte so I guess I'll add SAMPLE_LABEL's to improve this profile; I don't see something more useful for me to do here; perhaps you have suggestions.
> But, surely it's not considered OK that we take about 10 seconds to reflow this page.

I'm a bit surprised by that too; see comment 19.

For what it's worth, on my fast laptop the page takes about 30-40ms to render.  I guess it's possible that the phone is 250x slower, but it seems a little fishy.
Does it change if you set the font.size.inflation.minTwips pref to 0?
How common layout/content/page is our open source notice?  If it isn't common, perhaps we can change the content so that we don't invite this problem?  If it is common and we're going to hit a lot of other pages like this, then I guess we need to keep it a blocker.  Just stating the obvious, I guess.
Filed bug 827846 about the need to --disable-elf-hack to get symbols.
(In reply to David Baron [:dbaron] from comment #31)
> Does it change if you set the font.size.inflation.minTwips pref to 0?

This doesn't seem to affect visibly the time it takes to render this page.
Here is a new profile with a lot of SAMPLE_LABEL's all over the text layout code.

http://people.mozilla.com/~bgirard/cleopatra/#report=aaafd649dff13e7e1476991d0506cafe7e264258

Do you see something new in it? Any place where you'd like me to add more SAMPLE_LABEL's?
> Do you see something new in it?

Maybe!  70% of the time is under textrun creation from nsLineLayout::TrimTrailingWhiteSpaceIn.  But I thought that happened after layout was done for the line.  And that means that those frames should presumably already have textruns, no?
Flags: needinfo?(roc)
Yes!
Flags: needinfo?(roc)
Blocks: 828210
There is a simple workaround in Gaia for it. Let's renominate this since there is still a real bug but it's maybe not a blocker anymore.
blocking-basecamp: + → ?
(In reply to Vivien Nicolas (:vingtetun) from comment #38)
> There is a simple workaround in Gaia for it. Let's renominate this since
> there is still a real bug but it's maybe not a blocker anymore.

Agreed.  I've moved bug 828210 to Gaia:System.  Let's mark this as something we'd like to see in B2G 1.x but not a blocker for basecamp.

If there's a patch for this soon, please request approval for uplift.
blocking-basecamp: ? → -
Assignee: bjacob → nobody
Whiteboard: [b2g-gfx]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.