Closed Bug 1455841 Opened 7 years ago Closed 7 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 (deleted) —
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.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: