Ryan VanderMeulen [:RyanVM] Reporter
	Description • 10 years ago

I noticed today that when Treeherder updates the data, the job results column does a little side-to-side shaking due to the width changing back and forth.

	Jonathan French (:jfrench)
	Comment 1 • 10 years ago

I saw this a lot late last night, with 4-5 resultsets containing many pending/running jobs being constantly updated.

	Ed Morley [:emorley]
	Comment 2 • 10 years ago

(Reducing the number of P1 bugs at any one time, so there are a half dozen or so top issues on which efforts can be focused)

	Ed Morley [:emorley]
	Comment 3 • 10 years ago

Raising priority based on sheriffs top-picks of P2s.

	Jonathan French (:jfrench)
	Comment 4 • 10 years ago

Fwiw the jittering on Firefox is significantly worse than Chrome. At least on Windows. That may inform the fix.

	Mauro Doglio [:mdoglio]
	Comment 5 • 9 years ago

This should be mitigated by bug 1101040

	Jonathan French (:jfrench)
	Comment 6 • 9 years ago

It seems an approximation STR w/Firefox is:

o load Try
o get-next another 50 pushes
o give it time for a least 1 job poll cycle (optional?)
o LMB-click and resize the browser width slowly

Expected: Smooth resize (like on Chrome)

Observed: Our shimmy/shake, similar to when new jobs trigger it.

	Jonathan French (:jfrench)
	Comment 7 • 9 years ago

I checked that in addition to Chrome, Safari and Opera appear fine also. No jiggle.

I tried altering/suppressing a few treeherder.css classes on our job-list clone target element and some child elements, but so far the same popping occurs on Firefox with the above STR.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 9 years ago

So I _think_ what's going on here is this:  the page takes a long time to relayout [citation needed, but in this case "long time" would need to be > 100ms, and I'm pretty sure that once you have enough result sets we're way over that line on this page].  So we end up triggering a reflow interrupt (this is where 100ms matters) and painting a state where some of the page has been reflowed at the new width and some has not.  At least toggling the "layout.interruptible-reflow.enabled" preference to false makes the problem go away for me, as does adding a window resize event handler that flushes layout.  Would be good if someone else who can reproduce confirmed those claims.

OK, so why the back-and-forth wiggle on partial layouts?  It's _possible_ that we're interrupting in the middle of some size-measuring stuff flexbox does, maybe... Not sure about that part.

	Ed Morley [:emorley]
	Comment 9 • 9 years ago

Since this doesn't occur in Chrome, Safari and Opera & I have no idea how to work around it on our side, I'm going to move this to platform.

bz, could you tweak the summary/component if something else would be better - thanks :-)

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 9 years ago

You could work around by flushing layout on resize and after adding new stuff to the DOM, if you really want to work around it...  I'm not sure you should; it would eliminate the wiggle at the cost of more jank.

	Sylvestre Ledru [:Sylvestre]
	Comment 11 • 6 years ago

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

	Sylvestre Ledru [:Sylvestre]
	Comment 12 • 6 years ago

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information