Closed Bug 1402493 Opened 7 years ago Closed 7 years ago

Refresh button gets stuck in disabled stop state when extension loads content in page

Categories

(Firefox :: Toolbars and Customization, defect, P1)

57 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 58
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- disabled
firefox57 + verified
firefox58 + verified

People

(Reporter: u602702, Assigned: jaws)

References

Details

(Keywords: regression, Whiteboard: [reserve-photon-animation])

Attachments

(3 files)

Attached image 2017-09-22_17-17-00.gif
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170917031738

Steps to reproduce:

Install "Reddit Enhancment suite and open any image, it will make the refresh button unresponsive and unable to be clicked. If you don't load anything, the button works as intended, as does it without the plugin. 

This is a very popular plugin and this could be affecting quite a few people.


Actual results:

The refresh button stops working when an image is loaded, forcing use of f5 or ctrl-r.


Expected results:

The refresh button should be able to be clicked after the image has finished loading.
Regression range between 2017-08-01 and 2017-08-04, most likely regressed by Bug 1386255.
Blocks: 1386255
Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Untriaged → Toolbars and Customization
Ever confirmed: true
Keywords: regression
Summary: Refresh button becomes unresponsive when loading images from certain websites, specifically Reddit with the RES plugin. → Refresh button gets stuck in disabled stop state when extension loads content in page
Whiteboard: [reserve-photon-animation]
Whiteboard: [reserve-photon-animation] → [photon-animation] [triage]
[Tracking Requested - why for this release]: add-on related issue that can cause the browser chrome to get in a broken state
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [photon-animation] [triage] → [reserve-photon-animation]
See Also: → 1401943
Flags: qe-verify?
I have confirmed via mozregression that bug 1386255 is the cause of this.
Comment on attachment 8912919 [details]
Bug 1402493 - Don't prevent switching back to Reload for top level about: loads.

https://reviewboard.mozilla.org/r/184230/#review189696

Tentative r+, see comment below.

::: browser/base/content/browser.js:5057
(Diff revision 1)
>      }
>      this.reload.setAttribute("displaystop", "true");
>    },
>  
>    switchToReload(aRequest, aWebProgress) {
> -    if (!this.ensureInitialized() || !this._shouldSwitch(aRequest, aWebProgress) ||
> +    if (!this.ensureInitialized() || !this.reload.hasAttribute("displaystop")) {

Your reasoning makes sense, but are you sure we should do this even if there's no request or the request has no URI at all? It doesn't look like we check that right now, and neither does the caller.
Attachment #8912919 - Flags: review?(gijskruitbosch+bugs) → review+
Comment on attachment 8912919 [details]
Bug 1402493 - Don't prevent switching back to Reload for top level about: loads.

https://reviewboard.mozilla.org/r/184230/#review189696

> Your reasoning makes sense, but are you sure we should do this even if there's no request or the request has no URI at all? It doesn't look like we check that right now, and neither does the caller.

The _shouldSwitch function returns true if there is no aRequest and it also returns true if there is no aRequest.originalURI, so this isn't a change in behavior for those two inputs.
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e595d08c3ee2
Don't prevent switching back to Reload for top level about: loads. r=Gijs
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> Comment on attachment 8912919 [details]
> Bug 1402493 - Don't prevent switching back to Reload for top level about:
> loads.
> 
> https://reviewboard.mozilla.org/r/184230/#review189696
> 
> > Your reasoning makes sense, but are you sure we should do this even if there's no request or the request has no URI at all? It doesn't look like we check that right now, and neither does the caller.
> 
> The _shouldSwitch function returns true if there is no aRequest and it also
> returns true if there is no aRequest.originalURI, so this isn't a change in
> behavior for those two inputs.

Ah, of course it does - clearly I misread it. Down with 6-line conditionals, I say! ;-)
https://hg.mozilla.org/mozilla-central/rev/e595d08c3ee2
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Hi Jared, should we uplift this to Beta57?
Flags: needinfo?(jaws)
Comment on attachment 8912919 [details]
Bug 1402493 - Don't prevent switching back to Reload for top level about: loads.

Approval Request Comment
[Feature/Bug causing the regression]: bug 1386255
[User impact if declined]: stop/reload button may get stuck on stop
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: reverts to behavior that we had for the stop->reload switching pre-57.
[String changes made/needed]: none
Flags: needinfo?(jaws)
Attachment #8912919 - Flags: approval-mozilla-beta?
Comment on attachment 8912919 [details]
Bug 1402493 - Don't prevent switching back to Reload for top level about: loads.

Photon related, Beta57+
Attachment #8912919 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attached image refresh available.gif
This bug is verified on Firefox 57.0b5 (20171002181526) and Firefox 58.0a1 (20171002220204) under Windows 10 64bit/Mac OS X 10.12.3.

Please see the attached video.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: