1113155 - Nightly: Browser resize event fails to reach document when e10s disabled

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Codacoder]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Steps to reproduce:

1. Open Nightly and Aurora side-by-side
2. Navigate to cnn.com in both
3. Resize Nightly window - witness slow repainting of webpage and browser against desktop
4. Test Aurora - works fine

Comment 1

[Codacoder]

This is now worse than before - the "final" resize event (I'm using throttling) never occurs which means the hosted document does not receive the notification to resize DIVs etc. Clicking away from the browser (eg, click desktop) causes the even to be sent.

Comment 2

[Codacoder]

Still broken and still UNCONFIRMED? If this makes its way into Dev Edition it'll be a showstopper here.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

So is this about repainting or about resize event?
(layout dispatches resize, so moving tentatively there.)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

On linux resizing cnn.com works just fine on Nightlies.

Comment 5

[Codacoder]

(In reply to Olli Pettay [:smaug] from comment #3)
> So is this about repainting or about resize event?
> (layout dispatches resize, so moving tentatively there.)

As a cause? I've no idea - I don't know the code. From a page/JS code POV, I'm not getting a resize event and from a user perspective, browser UI artifacts are left behind on the desktop (for both shrink and expand of browser's right border).  Works fine in all but Nightly - appeared the day I posted this bug.

Comment 6

[:Gijs (he/him)]

(In reply to Russ from comment #5)
> (In reply to Olli Pettay [:smaug] from comment #3)
> > So is this about repainting or about resize event?
> > (layout dispatches resize, so moving tentatively there.)
> 
> As a cause? I've no idea - I don't know the code. From a page/JS code POV,
> I'm not getting a resize event and from a user perspective, browser UI
> artifacts are left behind on the desktop (for both shrink and expand of
> browser's right border).  Works fine in all but Nightly - appeared the day I
> posted this bug.

Hey Russ, can you try using mozregression to figure out exactly what broke this? ( http://mozilla.github.io/mozregression/ )

Comment 7

[Codacoder]

(In reply to :Gijs Kruitbosch from comment #6)

> 
> Hey Russ, can you try using mozregression to figure out exactly what broke
> this? ( http://mozilla.github.io/mozregression/ )

Sure.  That's a cool looking tool.

I just updated Nightly to check - same issue.

See attachment.

Comment 8

[Codacoder]

Attachment: 1113155.png

Desktop image showing incomplete resize/repaint on today's CNN.com in Nightly.

Comment 9

[Codacoder]

Oh great... it just arrived in Dev Edition (Aurora). Guess I better down-tools and do that mozregression test.  This is a serious issue for our test env.

Comment 10

[Codacoder]

13:04.55 LOG: MainThread Bisector INFO Last good revision: 3e7232eebf3f
13:04.55 LOG: MainThread Bisector INFO First bad revision: 9eca1a2f90f0
13:04.55 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e7232eebf3f&tochange=9eca1a2f90f0

Which, if I'm reading this correctly, is mentioning bug:1090518 - if you guys can expedite this I'd REEEAAAALLLLLY appreciate it!

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Russ from comment #10)
> 13:04.55 LOG: MainThread Bisector INFO Last good revision: 3e7232eebf3f
> 13:04.55 LOG: MainThread Bisector INFO First bad revision: 9eca1a2f90f0
> 13:04.55 LOG: MainThread Bisector INFO Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=3e7232eebf3f&tochange=9eca1a2f90f0

That doesn't make much sense.  Are you sure?

Comment 12

[Codacoder]

Am I sure of what? A cut and paste? uh... yeah.

(In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #11)
> (In reply to Russ from comment #10)
> > 13:04.55 LOG: MainThread Bisector INFO Last good revision: 3e7232eebf3f
> > 13:04.55 LOG: MainThread Bisector INFO First bad revision: 9eca1a2f90f0
> > 13:04.55 LOG: MainThread Bisector INFO Pushlog:
> > https://hg.mozilla.org/integration/mozilla-inbound/
> > pushloghtml?fromchange=3e7232eebf3f&tochange=9eca1a2f90f0
> 
> That doesn't make much sense.  Are you sure?

Comment 13

[Codacoder]

@Gijs (or anyone) How do I cleanup after mozregression? Is there anything I need to do? (that was a ton of downloading)

Comment 14

[:Gijs (he/him)]

(In reply to Russ from comment #13)
> @Gijs (or anyone) How do I cleanup after mozregression? Is there anything I
> need to do? (that was a ton of downloading)

It all goes to a temp folder, so you shouldn't need to do any tidying up.

Comment 15

[:Gijs (he/him)]

Russ, I know this is frustrating, but David is right that this regression range looks like it is very unlikely to be causing your issue.

Can you doublecheck your results and tell me if these two builds are buggy for you or not:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1418056717/

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1418051737/

and, if you still have the terminal log from mozregression, do you have the pushlog for mozilla-central (before you told it to continue with inbound builds) ?

Comment 16

[Codacoder]

Luckily, I kept it open :)

> and, if you still have the terminal log from mozregression, do you have the
> pushlog for mozilla-central (before you told it to continue with inbound
> builds) ?

Is this what you mean?

 5:11.86 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightlies...
 5:11.86 LOG: MainThread Bisector INFO Last good revision: 035a951fc24a
 5:11.86 LOG: MainThread Bisector INFO First bad revision: f1f48ccb2d4e
 5:11.86 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=035a951fc24a&tochange=f1f48ccb2d4e

Comment 17

[Codacoder]

(In reply to :Gijs Kruitbosch from comment #15)
> Russ, I know this is frustrating, but David is right that this regression
> range looks like it is very unlikely to be causing your issue.
> 
> Can you doublecheck your results and tell me if these two builds are buggy
> for you or not:
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32/1418056717/
> 
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32/1418051737/
> 
> and, if you still have the terminal log from mozregression, do you have the
> pushlog for mozilla-central (before you told it to continue with inbound
> builds) ?

They're both 404s

Comment 18

[Codacoder]

I maybe should have mentioned this up-thread...

The (what I'm calling) "final repaint" can be triggered by taking focus away from the browser (by clicking on either the desktop or another running app).  I dunno if that helps?

Comment 19

[:Gijs (he/him)]

(In reply to Russ from comment #17)
> (In reply to :Gijs Kruitbosch from comment #15)
> > Russ, I know this is frustrating, but David is right that this regression
> > range looks like it is very unlikely to be causing your issue.
> > 
> > Can you doublecheck your results and tell me if these two builds are buggy
> > for you or not:
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> > inbound-win32/1418056717/
> > 
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> > inbound-win32/1418051737/
> > 
> > and, if you still have the terminal log from mozregression, do you have the
> > pushlog for mozilla-central (before you told it to continue with inbound
> > builds) ?
> 
> They're both 404s

Ah, brilliant. So they disappeared inbetween when you did the mozregression run and when I commented - either that, or I don't know where to look (the URLs above are what treeherder, our continuous integration monitoring tool (like travis) says where the builds should be). :-(

The m-c pushlog is what I meant, yes, and that's useful... It matches the inbound pushlog, at least. I don't really have much of any other ideas right now. Let's wait to see what Jeff says.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

It seems pretty unlikely that bug 1090518 is the cause? Can you reproduce the issue on multiple machines? Does the problem only happen on cnn.com?

Comment 21

[Codacoder]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #20)
> Can you reproduce the issue on multiple machines? 

Sorry, I don't have multiple machines.

> Does the problem only happen on cnn.com?

No that's an example everyone can access.  In my app, where multiple elements are listening for resize event, it appears much worse.

My hardware: Off the shelf DELL XPS (I'll get the gfx card info if you want it?)

History: this appeared in Nightly pretty much as I first reported causing me to switch to Aurora.  The bug then appeared in Aurora (now Dev Ed.) on Jan 15 or 16. (which is a real **** for me! :(

I have to say, while running mozregression and seeing many Nightly editions run unaffected, it also seemed "snappier" and much more responsive - when the bad ones appeared the bug was so obvious, the browser repaint seemed slugish in comparison.

Comment 22

[Jeff Muizelaar [:jrmuizel]]

(In reply to Russ from comment #21)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #20)
> > Can you reproduce the issue on multiple machines? 
> 
> Sorry, I don't have multiple machines.
> 
> > Does the problem only happen on cnn.com?
> 
> No that's an example everyone can access.  In my app, where multiple
> elements are listening for resize event, it appears much worse.
> 
> My hardware: Off the shelf DELL XPS (I'll get the gfx card info if you want
> it?)
> 
> History: this appeared in Nightly pretty much as I first reported causing me
> to switch to Aurora.  The bug then appeared in Aurora (now Dev Ed.) on Jan
> 15 or 16. (which is a real **** for me! :(
> 
> I have to say, while running mozregression and seeing many Nightly editions
> run unaffected, it also seemed "snappier" and much more responsive - when
> the bad ones appeared the bug was so obvious, the browser repaint seemed
> slugish in comparison.

Yeah, the gfx info from about:support might be helpful. Also, can you try getting a regression range again? You should be able to post the larger range from the nightly builds (before it switches to inbound builds) which tends to be more accurate.

Comment 23

[Codacoder]

You'll need to explain what you mean about running mozregression again - I just play dumb robot typing "good" or "bad"... not sure how I'd get what you're asking for.

Here's the gfx dump from about:support - let me know if you want any more info:

Adapter Description: AMD Radeon HD 6700 Series
Adapter Description (GPU #2): Intel(R) HD Graphics
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter Drivers (GPU #2): igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM: 1024
Adapter RAM (GPU #2): Unknown
ClearType Parameters: D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400 ]
Device ID: 0x68b8
Device ID (GPU #2): 0x0102
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 10-8-2013
Driver Date (GPU #2): 12-12-2012
Driver Version: 13.152.1.8000
Driver Version (GPU #2): 9.17.10.2932
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 30001002
Subsys ID (GPU #2): 0000000c
Vendor ID: 0x1002
Vendor ID (GPU #2): 0x8086
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6700 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 24

[Jeff Muizelaar [:jrmuizel]]

(In reply to Russ from comment #23)
> You'll need to explain what you mean about running mozregression again - I
> just play dumb robot typing "good" or "bad"... not sure how I'd get what
> you're asking for.

Part way through running mozregression it will print out a regression window that looks like:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=...&... it then switches to a separate sets of builds and prints out a different window at the end. I'm interested in the first window.

Comment 25

[:Gijs (he/him)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #24)
> (In reply to Russ from comment #23)
> > You'll need to explain what you mean about running mozregression again - I
> > just play dumb robot typing "good" or "bad"... not sure how I'd get what
> > you're asking for.
> 
> Part way through running mozregression it will print out a regression window
> that looks like:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=...&... it
> then switches to a separate sets of builds and prints out a different window
> at the end. I'm interested in the first window.

The original m-c one is in comment 16.

Comment 26

[Jeff Muizelaar [:jrmuizel]]

Ok, this is probably bug 1107297

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

[Tracking Requested - why for this release]:  Seems like a pretty serious regression for some set of users.

Comment 28

[Codacoder]

Thanks Gijs, Jeff and David.  Can someone tell me when I'll see a fix land in Nihgtly/DevEdition?

Comment 29

[Olli Pettay [:smaug][[e-mail]]]

You'll see the fix landed to Nightly when this bug is marked fixed.

Comment 30

[Codacoder]

@Jeff - FYI: Behavior of latest Nightly has changed in that when this bug occurs, the entire window goes black (it sometimes will repaint, but not always).

Comment 31

[Jeff Muizelaar [:jrmuizel]]

The bug that caused this has some big dependencies. We're going to try and have a fix or back out by Friday

Comment 32

[Codacoder]

Cool.

Prior to Friday, if you don't have a repeatable test framework for this and you want me to test a build (and don't mind handholding me a little) let me know.

Comment 33

[Lawrence Mandel [:lmandel] (use needinfo)]

Jeff - Are you taking this one?

Comment 34

[Bas Schouten (:bas.schouten)]

I suspect this will be fixed by the fix in bug 1117925.

Comment 35

[Jeff Muizelaar [:jrmuizel]]

This should be fixed now.

Comment 36

[Codacoder]

Latest Nightly?  I'm seeing a big improvement but shrinking the browser width from the right sometimes leaves a large black unpainted area at the bottom of the browser window.  And using the CNN.com website, it's not as slick on resize as current firefox.

Actually, I'm seeing the same sluggishness in Dev Edition (but no black area).

But if my latest Nightly is not the correct release to see the fix, ignore this.

Comment 37

[Codacoder]

Not sure what to tell you guys, first thoughts are, this bug is now a lot less obvious, repainting is way quicker, but the overriding problem described in the title is still there and seemingly worse "Final resize event doesn't reach document".  Now let me expand on why it's worse (it's possible I missed these symptoms before)

1 - shrink right side of browser window
2 - browser chrome freezes:
  - min-max-close buttons have disappeared
  - browser tabs don't function
  - "+" new tab does not function
  - where a horizontal scrollbar should appear on the window, it does not
3 - final resize event does not hit window so doc/body/children HTML layout is not updated
4 - Take focus from firefox (no longer foreground window) and the event finally arrives or...
  - wait an indeterminate amount of time (30secs?) and the event *may* arrive

It looks to me that the fix has merely fixed the problems depicted in the images I sent where you could see the "ghost" border trails on the right side of the browser.  That problem is clearly fixed.  The original bug, as reported, is not.

I've received two updates to nightly and dev ed. since Jeff's last post - hope this purported fix is now present in my system (?)

Comment 38

[Milan Sreckovic [:milan] (needinfo for best results)]

This appears to have gotten stuck, probably because there were a couple of bugs involved; one in graphics, that now seems to be taken care of, and another one with "resize event doesn't reach document".  It's now likely misfiled, and not getting enough attention because of it.

Russ, when you were doing the regression range, were you looking at the visual problems, or were you looking at the "final resize events"?  In other words, is the regression range still valid for what's left in this bug?

Wonder if we should spin up another bug for the left over problems, it may be too confusing to have it all in here.

Comment 39

[Codacoder]

(In reply to Milan Sreckovic [:milan] from comment #38)
> This appears to have gotten stuck, probably because there were a couple of
> bugs involved; one in graphics, that now seems to be taken care of, and
> another one with "resize event doesn't reach document".

I think I can agree with the sentiment (I'm not ff codebase aware enough to really know where a problem might lie so...)

Latest Dev Edition is now sending out resize - whether I'm now getting the final resize is harder to determine.  I think I am getting ti in as much as my large-grained elements are behaving as expected.  However, read on...

>  It's now likely
> misfiled, and not getting enough attention because of it.
> 
> Russ, when you were doing the regression range, were you looking at the
> visual problems, or were you looking at the "final resize events"?  

In short, I was looking at visual problems made evident by my code not receiving the resize event - so, "symptoms not causes".

Calling this "final resize" was my educated guess... I could have called it "Resizing is broken" and left it at that.  Since I'm using throttling, and since I could wait for like 2 minutes for the resize to arrive... I chose "fails to reach".  Hope that helps your understanding of how the problem is perceived.  

Now...

> In other
> words, is the regression range still valid for what's left in this bug?

Keeping what I've said in mind, I'm going to say yes.  How much reliable weight that "yes" carries, is up to you ;)
 
> Wonder if we should spin up another bug for the left over problems, it may
> be too confusing to have it all in here.

Sum up: I'm getting resize events. Black unpainted areas (bottom of window) are evident if I mess around repeatedly with firefox window borders, resizing over and over.

HTH.

Comment 40

[Lawrence Mandel [:lmandel] (use needinfo)]

Jet - Over to your team. Can you please find someone to pick up where the gfx team left off? Or, we can file a follow-up as Milan suggests in comment 38.

Comment 41

[Jet Villegas (inactive)]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #40)
> Jet - Over to your team. Can you please find someone to pick up where the
> gfx team left off? Or, we can file a follow-up as Milan suggests in comment
> 38.

I'm not sure this is a Layout bug (ie. black regions in repainted areas) per comment 39 but we'll pick this up if it's stuck and deemed important. Several comments suggested bugs that may also fix this (eg. bug 1117925.) Can we confirm how this behaves now that those fixes are in the tree? A reduced test case will also help. Thanks!

Comment 42

[Codacoder]

I read Jet's response and checked Dev Edition - same issue. I updated Nightly and it seems the resize issue is back.  See latest attachment - no window min/max/close buttons.

I apologize of these reports are confusing - but then so is the bug :/

Comment 43

[Codacoder]

Attachment: 1113155-cnn.png

Comment 44

[Codacoder]

And if "jittery, jerky and uncomfortable" can be seen as "flickering" I'd suggest that 1117925 is not fixed, IMO.

Comment 45

[Codacoder]

Clue?

Win7 -> VirtualBox -> Win10 Tech Preview -> Firefox Dev Edition - No fault found
Win7                                     -> Firefox Dev Edition - Fault as previously described.

Same PC/Win7.

Comment 46

[Jet Villegas (inactive)]

Russ: Let's try to isolate your resize event bug from he graphic glitches you're reporting. Can you test this page on your computer and tell me if you're getting resize events?

http://media.junglecode.net/test/1113155/resizetest.html

I'd like to then modify this test so that it reproduces the bug you're seeing.

Comment 47

[Codacoder]

Attachment: 1113155-jet1.png

Jet - the issue is not that resize events don't happen... it's that a final resize event doesn't always arrive.  See these two attachments: one showing your test, one showing my app. In both cases, a "final resize" is missing (browser has not updated its chrome).

Comment 48

[Codacoder]

Attachment: 1113155-jet2.png

Comment 49

[Jet Villegas (inactive)]

I can't reproduce the symptoms you're seeing on my Windows 7 machine. I thought the event you were referring to was in JS, but now I see that it's your scrollbars not updating when they should. That's a very strange machine-specific invalidation bug indeed.

Milan: have you got an AMD Radeon HD 6700 Series card over there?

Comment 50

[Codacoder]

(In reply to Jet Villegas (:jet) from comment #49)
> I can't reproduce the symptoms you're seeing on my Windows 7 machine. I
> thought the event you were referring to was in JS, but now I see that it's
> your scrollbars not updating when they should.

All the chrome: min/max/close buttons, too.  This is the only thing I can show you that speaks to me of a missing "final resize".  For my app, my large-grained divs etc don't adjust to the final window geometry, etc.

> That's a very strange
> machine-specific invalidation bug indeed.

Agreed.  And also why I thought comment 45 might be of interest.  Plus, (and perhaps very loosely related now that we're considering hardware specifics), you might want to check https://bugzilla.mozilla.org/show_bug.cgi?id=967096  <- my #1 all-time **** me off the most bug ;)

Comment 51

[Milan Sreckovic [:milan] (needinfo for best results)]

Russ, one more question - do you have e10s disabled on nightly?  I don't have the min/max/close buttons disappear, but I do see some nasty looking things happening in that area when I have e10s disabled on nightly; not nearly as bad with e10s on nightly, nor on dev edition (which has e10s disabled.)

Comment 52

[Codacoder]

(In reply to Milan Sreckovic [:milan] from comment #51)
> Russ, one more question - do you have e10s disabled on nightly?

Yes. Disabled in Nightly and Dev Ed. (I forget why, but I did have issues (or suspicions) unrelated to this bug)

>  I don't
> have the min/max/close buttons disappear, but I do see some nasty looking
> things happening in that area when I have e10s disabled on nightly; not
> nearly as bad with e10s on nightly, nor on dev edition (which has e10s
> disabled.)

I'll retest in both Nightly and Dev Ed. with e10s enabled and report back.

Comment 53

[Codacoder]

Wow - sweet. Perfect and reliable resizing!

I had to restart in safe mode though - Nightly insisted that I had an accessibility tool active (not true AFAIK).

Comment 54

[Codacoder]

Seems likely my e10s setting is suffering from bug 1115956. That's a damn shame it's marked WONTFIX.

Comment 55

[Milan Sreckovic [:milan] (needinfo for best results)]

Interesting that nightly with e10s off is nasty, but dev edition with e10s off is not...

Comment 56

[Codacoder]

(In reply to Milan Sreckovic [:milan] from comment #55)
> Interesting that nightly with e10s off is nasty, but dev edition with e10s
> off is not...

If you're implying Dev Ed. is not suffering the bug, it *is*.  Today it seems a little less sluggish but it's definitely not as responsive (in terms of resize events) as Nightly+e10s.

Is there any way to launch e10s window in Dev Edition?

Comment 57

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Russ from comment #56)
> ...
> Is there any way to launch e10s window in Dev Edition?

For testing purposes, to get e10s in Dev Edition, you'd have to set browser.tabs.remote.autostart to true and layers.offmainthreadcomposition.testing.enabled to true.  If you have successfully gotten e10s, you'll see the tab text underlined.

Comment 58

[Jim Mathies [:jimm]]

We've fixed a few resize perf related bugs, including -

bug 1076820
bug 1096076
bug 1109654

This might be a dupe of one of those.

(In reply to Russ from comment #54)
> Seems likely my e10s setting is suffering from bug 1115956. That's a damn
> shame it's marked WONTFIX.

Can you post your about:support text for the system you test on? When a11y support is finished the disable prompt will come out. I'm curious though what type of accessibility software you're using, because it might have something to do with the perf problems you're seeing.

(In reply to Russ from comment #56)
> (In reply to Milan Sreckovic [:milan] from comment #55)
> > Interesting that nightly with e10s off is nasty, but dev edition with e10s
> > off is not...
> 
> If you're implying Dev Ed. is not suffering the bug, it *is*.  Today it
> seems a little less sluggish but it's definitely not as responsive (in terms
> of resize events) as Nightly+e10s.
> 
> Is there any way to launch e10s window in Dev Edition?

No, and please don't, it's unsupported and could break stuff in your profile. We have the pref hard coded off on every tree except mozilla-central.

I'm minusing this for e10s tracking for now. If testers find this to be a regression caused by an e10s landing though, please reset this flag back to '?'.

Comment 59

[Codacoder]

(In reply to Jim Mathies [:jimm] from comment #58)
> (In reply to Russ from comment #54)
> > Seems likely my e10s setting is suffering from bug 1115956. That's a damn
> > shame it's marked WONTFIX.
> 
> Can you post your about:support text for the system you test on? When a11y
> support is finished the disable prompt will come out. I'm curious though
> what type of accessibility software you're using, because it might have
> something to do with the perf problems you're seeing.

See below. 

> > Is there any way to launch e10s window in Dev Edition?
> 
> No, and please don't, it's unsupported and could break stuff in your
> profile. We have the pref hard coded off on every tree except
> mozilla-central.

Haven't. Won't ;)

Here's the dump from about:support

Application Basics
------------------

Name: Firefox
Version: 39.0a1
Build ID: 20150305072141
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Multiprocess Windows: 0/1 (default: false)

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Extensions
----------

Name: ADB Helper
Version: 0.7.4
Enabled: false
ID: [e-mail]

Name: Firefox OS 1.3 Simulator
Version: 7.0pre9.20140401
Enabled: false
ID: [e-mail]

Graphics
--------

Adapter Description: AMD Radeon HD 6700 Series
Adapter Description (GPU #2): Intel(R) HD Graphics
Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter Drivers (GPU #2): igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Adapter RAM: 1024
Adapter RAM (GPU #2): Unknown
ClearType Parameters: D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 400 ]
Device ID: 0x68b8
Device ID (GPU #2): 0x0102
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16571)
Driver Date: 10-8-2013
Driver Date (GPU #2): 12-12-2012
Driver Version: 13.152.1.8000
Driver Version (GPU #2): 9.17.10.2932
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 30001002
Subsys ID (GPU #2): 0000000c
Vendor ID: 0x1002
Vendor ID (GPU #2): 0x8086
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 6700 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size_cached_value: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 3
browser.download.importedFromSqlite: true
browser.download.useDownloadDir: false
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20150305072141
browser.startup.homepage: C:\code\qsi\home.html
browser.startup.homepage_override.buildID: 20150305072141
browser.startup.homepage_override.mstone: 39.0a1
browser.tabs.remote.autostart.disabled-because-using-a11y: true
browser.tabs.tabClipWidth: 99
browser.tabs.warnOnClose: false
browser.urlbar.autocomplete.enabled: false
browser.urlbar.suggest.bookmark: false
browser.urlbar.suggest.history: false
browser.urlbar.suggest.openpage: false
dom.mozApps.used: true
extensions.lastAppVersion: 39.0a1
font.internaluseonly.changed: false
gfx.direct3d.last_used_feature_level_idx: 0
media.gmp-gmpopenh264.enabled: false
media.gmp-gmpopenh264.lastUpdate: 1422557236
media.gmp-gmpopenh264.path: C:\Users\RUSS\AppData\Roaming\Mozilla\Firefox\Profiles\swce692l.Nightly\gmp-gmpopenh264
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.lastCheck: 1425585515
network.cookie.cookieBehavior: 1
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1425490391
places.history.enabled: false
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.flash: 0
plugin.state.java: 0
plugin.state.npappdetector: 0
plugin.state.npatgpc: 1
plugin.state.npctrl: 0
plugin.state.npdeployjava: 0
plugin.state.npgeplugin: 0
plugin.state.npgoogletalk: 0
plugin.state.npgoogleupdate: 0
plugin.state.npgtpo3dautoplugin: 0
plugin.state.npo1d: 0
plugin.state.nppdf: 0
plugin.state.npqtplugin: 0
plugin.state.npvlc: 0
plugin.state.npwlpg: 0
privacy.cpd.cookies: false
privacy.cpd.sessions: false
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.timeSpan: 0
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1425053711

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSSMIME
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSSSL
Expected minimum version: 3.18 Basic ECC Beta
Version in use: 3.18 Basic ECC Beta

NSSUTIL
Expected minimum version: 3.18 Beta
Version in use: 3.18 Beta

Experimental Features
---------------------

Comment 60

[Lawrence Mandel [:lmandel] (use needinfo)]

Jim - Russ provided the information that you requested in comment 59. What's next for this bug?

Comment 61

[Jim Mathies [:jimm]]

> Steps to reproduce:
> 
> 1. Open Nightly and Aurora side-by-side
> 2. Navigate to cnn.com in both
> 3. Resize Nightly window - witness slow repainting of webpage and browser
> against desktop
> 4. Test Aurora - works fine

I can reproduce using this basic test case. I can't reproduce in Nightly with e10s disabled. I also can't reproduce in aurora. Seems like an e10s specific perf bug at this point.

Comment 62

[Jim Mathies [:jimm]]

Also, I'm not sure why this is tracked for 37 and 38. 

Tracy, would you mind testing for this in 37/38?

I was comparing resize perf between two windows of two browsers to test. It's clear e10s is slower still when we redraw content after a resize. But it's not clear that we have a problem on other release channels.

Comment 63

[Lawrence Mandel [:lmandel] (use needinfo)]

(In reply to Jim Mathies [:jimm] from comment #61)
> I can reproduce using this basic test case. I can't reproduce in Nightly
> with e10s disabled. I also can't reproduce in aurora. Seems like an e10s
> specific perf bug at this point.

(In reply to Jim Mathies [:jimm] from comment #62)
> Also, I'm not sure why this is tracked for 37 and 38.

That seems to conflict with the reporters information. See comment 21, comment 37, comment 39, comment 41, and comment 56. AFAIK, 37 and 38 are affected. I would love to be corrected.

Comment 64

[Codacoder]

Latest tests:
Firefox Beta 37.0 - faulty
Firefox Dev Edition 38.0a2 (2015-03-16) - faulty
Firefox Nightly 39.0a1 (2015-03-16) - faulty*


*WITHOUT e10s - still can't enable e10s without jumping through hoops)

Comment 65

[Tracy Walker [:tracy]]

Russ, thanks for checking the latest builds across channels.  I actually don't have the correct hardware to test this. (Win7 64bit)

Comment 66

[Lawrence Mandel [:lmandel] (use needinfo)]

Given that we're building the final Beta in the 37 cycle tomorrow and we haven't made progress towards a fix, I think we're going to have to live with this in 37. We're going to need to reproduce and find an owner if we're going to fix this in 38. I'm marking this as wontfix for 37.

jet - Can you help push this one?

Comment 67

[Codacoder]

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #65)
> I actually don't have the correct hardware to test this. (Win7 64bit)

Which reminds me, I think perhaps comment #45 points to physical hardware/drivers related issues.  While that test was the same physical PC, the Win10 setup in the virtual machine is using different hardware and drivers (certainly for gfx, audio etc).

Comment 68

[Codacoder]

Firefox Dev Edition 38.0a2 (2015-03-19) - FIXED! (Really? What happened?)

Solid, smooth, no jitter, no shakey wakey... What damn fool went and fixed it? Come on. Own up. ;)

Comment 69

[Codacoder]

Damn - it's reappeared in today's Dev Edition.

Nightly is NOT broken.

Comment 70

[Liz Henry (:lizzard) (relman/hg->git project)]

Russ, thanks for all your testing here. Can you put in details from about:support for the broken version and what specifically isn't working now? It looks like the issues have morphed over the last few months. So we want to be very clear about what we should be trying to reproduce, and what your pref settings are when you see the issue.

Florin can someone on your team take a look with similar hardware/graphics setup to what Rus has?  I notice there may be separately diagnosable issues in a VM setup. 

Anthony or Tracy, is this something where we can also get time with betabreakers since this looks like an elusive issue that may be dependent on specific hardware?

Comment 71

[Codacoder]

Today's freshly updated Nightly and Dev Ed...

Dev Ed - a little on the jerky side while shrinking/expanding browser's right edge and lower-right corner.  Certainly not broken as it was in C69.

Nightly - PERFECT - no noticeable problem.

@Liz: I'm not sure it morphed as much as my understanding of where the fault was occurring improved :) And as regards my about:dump, you have it in C59 (I don't use these browsers/profiles for anything other than dev work so they're not having addons added/removed unless moz ships with them).

"Broken": As defined in the title of this bug and as shown in the numerous images attached.

Comment 72

[u279076]

(In reply to Liz Henry (:lizzard) from comment #70)
> Anthony, is this something where we can also get time with
> betabreakers since this looks like an elusive issue that may be dependent on
> specific hardware?

Probably not - I'd be happy to explain why offline. Suffice it to say they are more useful for finding new bugs than they are for debugging existing issues.

Comment 73

[Liz Henry (:lizzard) (relman/hg->git project)]

Thanks for the clarification. Sounds like this is a minor performance problem, not a black screen problem, then.

Comment 74

[Codacoder]

(In reply to Liz Henry (:lizzard) from comment #73)
> Thanks for the clarification. Sounds like this is a minor performance
> problem, not a black screen problem, then.

While "black screen" might be considered a critical problem, I would not describe the issue I reported as "minor".  Without a final resize event, "missing" HTML elements (not to mention missing and significant browser chrome) could easily render a web-app UI (and UX) uncomfortable if not unusable.

You know what guys - I'm done with this bug... frankly, it's going around in circles and I can do more than I have already done.

Comment 75

[Timothy Nikkel (:tnikkel)]

I think the patch for bug 1077085 could explain this. It is on nightly, but was backed out of beta and aurora. I could see it fixing an issue like this.

Comment 76

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

The closest we have to this is a Radeon HD 6450. According to comment 71 though, it would seem that the issue itself is not showing anymore. Bogdan could you perhaps give this a try when you have some time on Windows 7 x64 using the latest DevEdition?

Comment 77

[Codacoder]

Just updated Dev Ed. It is PERFECT. No jerky, cluncky resizing jitter, no black areas. Yesterday (perhaps Monday?) the whole bug was back - huge unpainted black areas, missing chrome elements, hopelessly broken.  So bad, I couldn't bring myself to comment on it so fed up with it.

I am not confident that any specific change has directly *fixed* the bug. FWIW, my suspicion is, there is a moving issue somewhere - a "compensating error (or errors)" that hides and reveals the problem as seemingly unrelated issues are exposed and fixed.  That doesn't help much, I know. But there it is.

Repeat: Today's Dev Ed is PERFECT.

Comment 78

[Bogdan Maris, Desktop QA]

(In reply to Russ from comment #77)
> Just updated Dev Ed. It is PERFECT. No jerky, cluncky resizing jitter, no
> black areas. Yesterday (perhaps Monday?) the whole bug was back - huge
> unpainted black areas, missing chrome elements, hopelessly broken.  So bad,
> I couldn't bring myself to comment on it so fed up with it.
> 
> I am not confident that any specific change has directly *fixed* the bug.
> FWIW, my suspicion is, there is a moving issue somewhere - a "compensating
> error (or errors)" that hides and reveals the problem as seemingly unrelated
> issues are exposed and fixed.  That doesn't help much, I know. But there it
> is.
> 
> Repeat: Today's Dev Ed is PERFECT.

Based on this comment I don`t thing is necessary for me to try and test this anymore.

Comment 79

[Sylvestre Ledru [:Sylvestre]]

The backout of bug 1077085 fixed both 38 & 39. Updating the tracking flags and clearing the ni on jet

Comment 80

[Codacoder]

Nightly (40.0a1 (2015-04-22)), no e10s, is FIXED. 

However, an e10s window is resizing over and over without ever touching the browser edge to cause it to resize (mouseover code on various divs is making the browser change size - different bug?).

Comment 81

[Ryan VanderMeulen [:RyanVM]]

Russ, this works for me on a current nightly build. Same for you?

Comment 82

[Codacoder]

Thanks Ryan.

I have a new setup - my old setup contained umpteen profiles for various editions of firefox. That became a significant time-sink to manage... so when I built my new setup, I vowed never to do that again. Consequently, I now use only Dev Edition.  So, with that caveat, ...

I haven't seen this issue in Dev Edition (currently at 43.0a2)

Comment 83

[Ryan VanderMeulen [:RyanVM]]

Good enough for me, thanks :)