[Windows] "Screenshots went haywire" error message displayed for any screenshot taken and the Screenshots overlay wrongly remains displayed on root page

VERIFIED FIXED in Firefox 56

Status

defect
VERIFIED FIXED
2 years ago
Last year

People

(Reporter: poiegas, Unassigned)

Tracking

(Blocks 1 bug)

56 Branch
mozilla56
All
Windows
Dependency tree / graph

Firefox Tracking Flags

(firefox56 verified)

Details

[Regression]:
- This issue is caused by a Nightly regression that started with the build from July 11th. Here is the pushlog link: https://goo.gl/SKjisQ.
- The same Firefox regression caused issues for Notes experiment.

[Affected versions]:
- Nightly 56.0a1 (2017-07-11) and above

[Affected Platforms]:
- All Windows

[Steps to reproduce]:
1. Start the latest Nightly build and navigate to a web page (eg: youtube.com)
2. Click the "Screenshots" icon from browser toolbar.
3. Click the "Skip" button from bottom left of the "Tour" pop-up.
4. Make a selection and click on "Save" button or select one of the available capture options.
5. Observe the browser behavior. 
6. Close the screenshot page and observe the root page.

[Expected result]:
- Step 5: A new tab is opened where the screenshot take is displayed and a notification message appears that informs you that the screenshot was copied to clipboard.
- Step 6: The Screenshots overlay is no longer displayed on the root page. 

[Actual results]:
- Step 5: A new tab is opened where the screenshot is loaded, but 2 notification messages with "Whoa! Firefox Screenshots went haywire." message are displayed.
- Step 6: The Screenshots overlay is still displayed on the page.

[Additional Notes]:
- You cannot take another screenshot on the root page while the overlay is displayed. None of the options is working (selection, entire page or visible).  
- Here is a screen recording of the issue: https://goo.gl/G1PCC5
- Browser Console error: https://goo.gl/C8D7Ym
Hi Kris, can you please look at this issue? After running a regression window, it seems to be caused by something that you have changed on July 11th (pushlog: https://goo.gl/SKjisQ).

Thanks!
Flags: needinfo?(kmaglione+bmo)
Blocks: webext-oop
https://hg.mozilla.org/integration/mozilla-inbound/rev/ba71ef77f7d3f36367def85cf8be8d9933654232
Bug 1381023: Don't treat no response as an error in hybrid extension message handling. r=trivial
Duplicate of this bug: 1381086
Kris, does this fix async messages for both background scripts and SDK/bootstrap scrips?

Thanks for the prompt fixes!
(In reply to Jonathan Kingston [:jkt] from comment #5)
> Kris, does this fix async messages for both background scripts and
> SDK/bootstrap scrips?

Presumably. There shouldn't really be any difference between the two.

However, SDK support is going away in about 3 weeks, so I'm not especially concerned about it for the most part.
Flags: needinfo?(kmaglione+bmo)
https://hg.mozilla.org/mozilla-central/rev/ba71ef77f7d3
https://hg.mozilla.org/mozilla-central/rev/52c077337a3b
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Firefox: 57.0a1, Build ID: 20170912220343

I have retested this issue on latest Nightly (57.0a1) build and latest Beta (56.0b11) and the issue is no longer reproducible. Tested on Windows 10 x64 and Windows 7 x64.

I can confirm that the issue is reproducible on older Nightly builds (eg: the build from 2017-07-11).
Status: RESOLVED → VERIFIED
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.