Closed Bug 1455841 Opened 2 years ago Closed 2 years ago
Tab loading throbber doesnt throb while page is loading
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180421100143 Steps to reproduce: Create new profile. Enable WR. Restart browser. Go to https://jwatt.org/tmp/load-never-finishes.php Actual results: the throbber in the tab is "stuck" Expected results: not so
Thank you! Nightly 61 x64 20180421100143 de_DE dd0e54d786743974a50a338059bcd68a09b6d5b2 @ Debian Testing (KDE, Radeon RX480) Now I got the update and can reproduce. (Next time I'll directly try the latest inbound build without waiting.) mozregression --good 2018-04-20 --bad dd0e54d786743974a50a338059bcd68a09b6d5b2 --pref gfx.webrender.all:true startup.homepage_welcome_url:'https://jwatt.org/tmp/load-never-finishes.php' > 7:48.33 INFO: Last good revision: d1bcd80c9a73a647a583958bef60816ae90d3d6b > 7:48.33 INFO: First bad revision: b758bc75b0549db2d047539663c98f6f87ffd19b > 7:48.33 INFO: Pushlog: > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d1bcd80c9a73a647a583958bef60816ae90d3d6b&tochange=b758bc75b0549db2d047539663c98f6f87ffd19b > b758bc75b054 Hiroyuki Ikezoe — Bug 1455315 - Use testing time stamp whenever we are on testing mode. r=kats
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
OS: Unspecified → All
Mozregression points to your change. Could you have a look, please?
Same regression range: https://bug1401665.bmoattachments.org/attachment.cgi?id=8910415 Actual: The circle only rotates if you move the mouse. (And after doing unknown steps it doesn't even do that.) Expected: It should permanently rotate.
In new code, when animTime = mPreviousFrameTimeStamp, line 1185 shows different result from old code. Old code: mPreviousFrameTimeStamp always becomes mCompositorScheduler->GetLastComposeTime() or cbp->GetTestingTimeStamp().ref() even if mPreviousFrameTimeStamp was sent to SampleAnimations. New code: mPreviousFrameTimeStamp can be unchanged when animTime = mPreviousFrameTimeStamp. Is this intended?
Definitely not! I made a silly mistake.
Assignee: nobody → hikezoe
Status: NEW → ASSIGNED
The code I wrote in bug 1455315 was pretty error-prone. Sorry about that. https://treeherder.mozilla.org/#/jobs?repo=try&revision=d70fb6bee45101ce6a96a13257629afb9f04fc46
Works fine with try build.
Comment on attachment 8970036 [details] Bug 1455841 - Don't update mPreviousFrameTimeStamp in the case of testing refresh mode. https://reviewboard.mozilla.org/r/238786/#review244488 Is it possible to write a test that exercises this behavior? It's kind of bad that we don't have a test that caught this.
Attachment #8970036 - Flags: review?(bugmail) → review+
Yeah, totally agree. I am surprised that no tests didn't catch this. I have no idea about the test case for now, but I keep thinking how to do that.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/8f6ffc8378e3 Don't update mPreviousFrameTimeStamp in the case of testing refresh mode. r=kats
Oh, I didn't realize that dom/animation/test/mozilla/test_deferred_start.html is skipped on WebRender unfortunately. And also there should be test cases in layout/style/test but maybe all of them are disabled on WebRender now.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
No longer blocks: 1362116
You need to log in before you can comment on or make changes to this bug.