Closed Bug 1455841 Opened 6 years ago Closed 6 years ago

Tab loading throbber doesnt throb while page is loading

Categories

(Core :: Graphics: WebRender, defect)

Unspecified
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox59 --- unaffected
firefox60 --- unaffected
firefox61 --- disabled

People

(Reporter: mayankleoboy1, Assigned: hiro)

References

()

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

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
Attached file aboutsupport.txt
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
Blocks: 1455315
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?
Flags: needinfo?(hikezoe)
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
Flags: needinfo?(hikezoe)
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 hikezoe@mozilla.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.
https://hg.mozilla.org/mozilla-central/rev/8f6ffc8378e3
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.