Closed Bug 1488361 Opened Last year Closed Last year

Clear Data / Manage Data (cookies and site data) buttons are deactivated on first run

Categories

(Firefox :: Preferences, defect, P1)

63 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 + verified
firefox64 + verified

People

(Reporter: evilpie, Assigned: ehsan)

References

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:
1. Compile mozilla-central
2. run ./mach run
3. Go to about:preferences#privacy
4. Observe that "Clear Data" and "Manage Data" are gray and can't be clicked
5. Reload the page
6. Buttons are clickable
Considering that we landed a ton of patches in preferences yesterday, I assume this was broken by the third party cookies work...

I'll try to find the regression...
Flags: needinfo?(jhofmann)
[Tracking Requested - why for this release]:
Users can not clear site data in about:preferences when browser.contentblocking.ui is true

Ehsan, this seems to have been caused by bug 1488310, probably some race/timing issue with moving the site data section. We should look into it.

I can confirm that nothing is broken when browser.contentblocking.ui is set to false, so beta users are not going to immediately be impacted by this, but we should still fix this in a timely manner.
Blocks: 1488310
Flags: needinfo?(jhofmann) → needinfo?(ehsan)
Priority: -- → P1
We should also figure out why tests are not catching this...
I can't reproduce this.  Better steps to reproduce are appreciated.

Based on the code, the *only* possible case that might be causing this (as in, the only code that disables both of these buttons) is something being clearing the site data in the background! <https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/browser/components/preferences/in-content/privacy.js#1944>  That seems completely unrelated to all of the recent changes that have landed in the past day.

Also, I don't understand the connection to bug 1488310 (that was duped against bug 1488436 right now), was that just a guess?  May I ask what based your suspicion?
Flags: needinfo?(ehsan) → needinfo?(jhofmann)
In my case, "Download Links" WebExtension make this issue.
https://addons.mozilla.org/ja/firefox/addon/download-links/

When the WebExtension is disabled, Clear Data / Manage Data buttons are activated.
(In reply to Takanori MATSUURA from comment #5)

Sorry. Comment #5 is incorrect.
Enable/Disable WebExtensions are not related this issue.

* Type "about:preferences#privacy" directly into the new tab, Clear Data / Manage Data buttons are active.
* Visit "about:preferences" and select "Privacy & Security", Clear Data / Manage Data buttons are inactive.
Hello,

Here is the Regression Range I found for this issue:

INFO: Last good revision: 75411571f3a4aeabbc1697b5dd7f4f827af3d29d
INFO: First bad revision: 8351581ba5a44684bdfbbcf731756cd5f785c46c

INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=75411571f3a4aeabbc1697b5dd7f4f827af3d29d&tochange=8351581ba5a44684bdfbbcf731756cd5f785c46c
(In reply to :Ehsan Akhgari from comment #4)
> I can't reproduce this.  Better steps to reproduce are appreciated.
> 


Steps to reproduce:
1. Launch Nightly
2. Open about:preferences#privacy
  --- Bug appears
3. Reload (f5)
  --- Bug Disappears

4. Re-launch Nightly
5. Open about:preferences#privacy
  --- Bug appears again
Blocks: 1488013
No longer blocks: 1488310
Version: unspecified → 63 Branch
I have tried everything I can possibly think of, and I still cannot reproduce this bug.

So I resorted to reading the code a bit more, and I have a theory as to what may be going on here.  First note how this code starts to update the sites immediately after setting up the observer notifications: <https://searchfox.org/mozilla-central/rev/c3fef66a5b211ea8038c1c132706d02db408093a/browser/components/preferences/in-content/privacy.js#410> and also note that SiteDataManager.updateSites() immediately dispatches the "sitedatamanager:updating-sites" notification <https://searchfox.org/mozilla-central/rev/5a18fb5aeeec99f1ca1c36a697082c221189a3b9/browser/modules/SiteDataManager.jsm#48>.  So the two buttons are disabled immediately after initialization.

Now, it is possible that the sitedatamanager:sites-updated notification is arriving before the XBL binding has been reattached to the elements, which would cause this code <https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/privacy.js#1949> to just set an expando "disabled" property on the node that has no effect whatsoever, in a very similar vain to what was happening in bug 1488013.

In order to avoid this whole mess of a race condition, we can simply start the initialization of these buttons after we've moved the UI elements, I think.
FYI,
With opt build (Windows 2012 x64 opt), I can reproduce the problem with 100% probability.

On the other hand, 
With debug build (Windows 2012 x64 debug), I can reproduce this problem with approx 80% probability. And sometimes I cannot reproduce.
Comment on attachment 9006630 [details]
Bug 1488361 - Only initiate the updating of site data control buttons after we have moved the buttons in the UI; r=johannh

Johann Hofmann [:johannh] has approved the revision.
Attachment #9006630 - Flags: review+
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a0e69b970c12
Only initiate the updating of site data control buttons after we have moved the buttons in the UI; r=johannh
(In reply to Alice0775 White from comment #11)
> FYI,
> With opt build (Windows 2012 x64 opt), I can reproduce the problem with 100%
> probability.
> 
> On the other hand, 
> With debug build (Windows 2012 x64 debug), I can reproduce this problem with
> approx 80% probability. And sometimes I cannot reproduce.

Thanks a lot, Alice.  Johann could reproduce the problem and he verified that this patch really fixes the issue.  :-)
https://hg.mozilla.org/mozilla-central/rev/a0e69b970c12
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Flags: needinfo?(jhofmann)
Assignee: nobody → ehsan
Comment on attachment 9006630 [details]
Bug 1488361 - Only initiate the updating of site data control buttons after we have moved the buttons in the UI; r=johannh

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1488013
[User impact if declined]: See comment 0
[Is this code covered by automated tests?]: No.
[Has the fix been verified in Nightly?]: It has been verified locally.
[Needs manual test from QE? If yes, steps to reproduce]: Yes, comment 0.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: Not too risky.
[Why is the change risky/not risky?]: The code change is rather small and localized, and is disabled by default.
[String changes made/needed]: None.
Attachment #9006630 - Flags: approval-mozilla-beta?
Comment on attachment 9006630 [details]
Bug 1488361 - Only initiate the updating of site data control buttons after we have moved the buttons in the UI; r=johannh

Uplift approved for 63 beta 5
Attachment #9006630 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I've also encountered reproducibility issues on Nightly 64 affected build(09/04/2018), but managed to reproduce it. (the trick is new profile)

Pending the beta uplifted, verified as fixed on Nightly 64 09/07/2018 Windows 10, Ubuntu 16.04 and Osx 10.13.
Verified as fixed Windows 10, Ubuntu 16.04 and Osx 10.13:
63.0b6 	20180913141435
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.