Affected versions

• Fx 67.0b13
• Fx 68.0a1

Affected platforms

• Windows 10 x64
• Ubuntu 18.04 LTS
• macOS 10.13

Steps to reproduce

1. Launch Firefox.
2. Go to about:preferences#privacy.
3. From the Content blocking area select the following options: Custom -> Cookies -> All cookies.
4. Go to https://edition.cnn.com/ and open the Site Information panel.
5. Click on "Report a problem", type a comment then click on "Send Report".
6. Open the "Report Problems" panel again.

Expected result

• The comment from step 5 is submitted.

Actual result

• The comment from step 5 is still displayed.

Regression range

• Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2858e470c2bcaa361b6809158921b01ed0f12d93&tochange=ffd3366e43f3e7fed749596dfacdb366d38e61ca
• Potential regressor: 1531532

(In reply to Cristian Comorasu, QA [:ccomorasu], Release Desktop QA from comment #0)

Regression range

• Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2858e470c2bcaa361b6809158921b01ed0f12d93&tochange=ffd3366e43f3e7fed749596dfacdb366d38e61ca
• Potential regressor: 1531532

The only patch in this range is just changing a reftest annotation, which can't have caused this bug. So the bisection result must be wrong. Setting flags to request another regression window.

Thank you, Kartikaya!
I will look into it as soon as possible.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=21e12842278a9d81100aafb8388ab53d90172190&tochange=9b7d9eccb34e0593c0b13e163469c37d396ccaee

Regressed by: 9b7d9eccb34e Tim Nguyen — Bug 1513343 - Remove textarea binding and replace usages with html:textarea. r=bgrins,dao

:ntim,
Your patch seems to cause the regression. Can you please look into this?

Without having looked deeply into this, my guess this that

• this is triggered via https://searchfox.org/mozilla-central/source/browser/base/content/browser-contentblocking.js#1032
• which opens https://searchfox.org/mozilla-central/source/browser/components/controlcenter/content/panel.inc.xul#317
• and populates the textarea https://searchfox.org/mozilla-central/source/browser/base/content/browser-contentblocking.js#992
• and then probably previously the XBL <destructor> ended up automatically clearing the value when the panel was hidden

So now we should probably add an else at https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/browser/base/content/browser-contentblocking.js#1013 that clears the value if the report was successful.

Comment on attachment 9060172 [details]
Bug 1546367 - Clear report textarea when report is submitted. r=bgrins

Beta/Release Uplift Approval Request

• User impact if declined: "Report breakage" subview does not clear the comments field when the report is submitted resulting in confusing user experience.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk, one line change covered by a new test
• String changes made/needed: none

https://hg.mozilla.org/mozilla-central/rev/99ad1e5017af

Comment on attachment 9060172 [details]
Bug 1546367 - Clear report textarea when report is submitted. r=bgrins

Minimal patch, low risk but fixes a visible bug for the end user, uplift approved for 67 beta 14, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/9cf0e5a84b2c

I can confirm this issue is fixed.
I verified on Fx 68.0a1 and Fx 67.0b14 using Ubuntu 18.04 LTS, macOS 10.14.3, Windows 10 x64 and Windows 7 x32.