1261355 - Resizing the window causes blank areas to be shown temporarily

Status: RESOLVED WONTFIX

(Core :: Panning and Zooming, defect)

Description

[Petruta Horea [:phorea], Desktop QA]

Attachment: resize.gif

[Note]:
- This is related to e10s and apz scrolling; I will search the regression range on Monday

[Affected versions]:
- Firefox 46 beta 7 - with e10s enabled
- latest Aurora 47.0a2
- latest Nightly 48.0a1 2016-03-31

[Affected platforms]:
- Win 7 64-bit
- Ubuntu 14.04 64-bit
- Mac OS X 10.10.5

[Steps to reproduce]:
1. Load http://usarugby.org/mens-eagles-news/item/arc2016-standings in a new tab while the browser window is in window-mode state
2. Drag the browser's margins in order to narrow / widen the window size

[Expected result]:
- The window is correctly resized without any jerkiness or rendering issues

[Actual result]:
- Repaint issues while resizing the window

[Additional notes]:
- Although Firefox 45 version is not affected by repaint issues, the resized areas are flashing

Comment 1

[Kartikaya Gupta (email:[e-mail])]

I think the issue that I'm seeing is a little different. When I resize the window vertically the content appears to stretch/shrink vertically as I'm dragging the window border. This happens on Windows but not OS X for me. It also happens on any page that I try, including this bugzilla page and other dead simple pages. My issue I can also reproduce with APZ and e10s disabled (on Nightly, didn't try other branches).

From your video I see a couple of frames near the end where it looks like the content stretches/shrinks vertically, which might be the same problem. However I also see some blank space at the bottom of the window when you're making the window larger - I think that part is intentional from e10s, because we want to allow the window to respond quickly to the user without waiting for the content to paint.

Can you confirm that this bug is about the content stretching/shrinking as the window is resizing? It sounds like the issue I'm seeing is something else though.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Attachment: What I'm seeing

This is what I'm seeing. This was taken with e10s disabled.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

(Also, the issue I'm seeing only happens on Windows, not OS X or Linux)

Comment 4

[Kartikaya Gupta (email:[e-mail])]

ni for the question at the end of comment 1.

Comment 5

[Petruta Horea [:phorea], Desktop QA]

I filled this issue for the blank space that appears when resizing from any margin. I believe that the repaint should happen faster/earlier.

I saw the stretching/shrinking too and I was about to log it, but this was already logged (see bug 1256728) as I found out when I searched for the regression range [1]. Although mozregression suggested bug 1250767 caused this regression, it appears that the culprit is bug 1232042.

[1] https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b5ec7338bddf9f1147e19c1d4d1b90a0cdb8da9a&tochange=1f9dc51c14938a3df662e80506cf80210e3422c0

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(In reply to Petruta Rasa [QA] [:petruta] from comment #5)
> I filled this issue for the blank space that appears when resizing from any
> margin. I believe that the repaint should happen faster/earlier.

Ok, thanks. I'll take another look to see if there's anything we can do about this.

> I saw the stretching/shrinking too and I was about to log it, but this was
> already logged (see bug 1256728) as I found out when I searched for the
> regression range [1]. Although mozregression suggested bug 1250767 caused
> this regression, it appears that the culprit is bug 1232042.

Ah, thanks! I wasn't aware of those bugs, and yeah - bug 1251778 sounds like what I'm seeing. On IRC Jeff said that Bas is still working on that. Anyway I guess that's a separate issue.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

So the page has a ton of resize event listeners which do a stuff - that alone is taking up > 9% of the time during a resize [1]. It's also triggering extra invalidations and repaints, it seems like.

I can reproduce the blank space showing up on OS X nightly pretty easily, and I can reproduce it regardless of APZ enabled or disabled. If I disable e10s it goes away, and AFAIK this is intentional as I mentioned in comment 1 ("because we want to allow the window to respond quickly to the user without waiting for the content to paint.") If I disable e10s and resize the window, the resizing is in fact a bit laggy and unresponsive (barely noticeable, unless you're looking for it) so this seems to me like it's all expected behaviour.

mconley, can you confirm that when resizing e10s windows we want to prioritize responsiveness of the chrome window, even if it means that some blank areas transiently appear during the resize because of unpainted content areas?

[1] https://cleopatra.io/#report=41bb4bcef8442c062e63f1094a6000c08f6fd507&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A22859888,%22end%22%3A22862149%7D%5D&selection=0,6784,6785,6786,6787,6283,6788,8,9,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,7095,169

Comment 8

[Mike Conley (:mconley) (:⚙️)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> 
> mconley, can you confirm that when resizing e10s windows we want to
> prioritize responsiveness of the chrome window, even if it means that some
> blank areas transiently appear during the resize because of unpainted
> content areas?
> 

I suspect so, but redirecting to canuckistani for confirmation.

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #8)
> (In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> > 
> > mconley, can you confirm that when resizing e10s windows we want to
> > prioritize responsiveness of the chrome window, even if it means that some
> > blank areas transiently appear during the resize because of unpainted
> > content areas?
> > 
> 
> I suspect so, but redirecting to canuckistani for confirmation.

Confirmed, everyone does this to some extent including chrome ( just checked ). To my eye dev edition and chrome are roughly equivalent here, but I'm no scientist.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Great, thanks for the confirmation! Since this is by design, I'm going to close as WONTFIX.