1495398 - Blocked type text cleared from dropdown_btn when selecting [Accept cookies and site data]

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect, P3)

Description

[Cristian Fogel [:cfogel]]

Attachment: aboutPreferences_cookies&SiteData.gif

[Affected versions]:
- 64.0a1 (2018-09-30), 63.0b10,

[Affected platforms]:
- Win10x64, macOS 10.13.4, Ubuntu 16.04LTS

[Steps to reproduce]:
1. Launch Firefox;
2. Click on the 3line-hamburger menu button;
3. Click on the Content blocking / Tacking protection option; (based on version)
4. Scroll to the Cookies and Site data section;
5. Click on the [Accept cookies and site data] option.

[Expected result]:
- content is displayed

[Actual result]:
- the text inside the dropdown button for [Block cookies and site data] type is no longer displayed

[Regression range]:
- for checking the regression I considered the issue where the text was no longer displayed after swapping. There where some other problems in versions in-between so the range might be affected by it (the dropdown not being dissabled at all); if this is not the case I can re-check it.

- pushlog url: https://hg.mozilla.org/integration/mozilla-inbound
- first bad: 2018-09-03 16:14:23.718000
- last good:  2018-09-03 15:56:54.366000

[Additional notes]:
- attached screen recording with the potential issue;

Comment 1

[:Gijs (away/busy until Mar 10)]

(In reply to Cristi Fogel [:cfogel] from comment #0)
> - pushlog url: https://hg.mozilla.org/integration/mozilla-inbound
> - first bad: 2018-09-03 16:14:23.718000
> - last good:  2018-09-03 15:56:54.366000

This link is broken. Can you re-run mozregression and paste the correct link?

For that date, the window looks vaguely like https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=2018-09-03&enddate=2018-09-04 but I don't know how to match up the timestamps, as it's unclear what timezone they're in. Either way, this seems like it's likely the result of one of Ehsan's patches to change this interface. He seems to be on PTO - Johann, can you have a look?

Comment 2

[:Gijs (away/busy until Mar 10)]

[Tracking Requested - why for this release]:
User-visible UI/UX regression that we shouldn't ship.

Comment 3

[Tanvi Vyas[:tanvi]]

This is expected behavior.  When the user clicks "Accept cookies and site data", the drop down no longer applies and hence is greyed out.  Closing this invalid.

Bryan, please chime in if you feel differently.

Comment 4

[Cristian Fogel [:cfogel]]

@Gjis:
Will re-check the regression range based on replies.

@tanvi
I agree that it being greyed out is an expected behaviour.

The bug refers to the text disappearing after the swap. I'm not sure that I know any other menus that would have this behavior.
Also, if that would be the case ... why isn't the text hidden as well in the first place(on the very first load)?

Comment 5

[Tanvi Vyas[:tanvi]]

(In reply to Cristi Fogel [:cfogel] from comment #4)
> @Gjis:
> Will re-check the regression range based on replies.
> 
> @tanvi
> I agree that it being greyed out is an expected behaviour.
> 
> The bug refers to the text disappearing after the swap. I'm not sure that I
> know any other menus that would have this behavior.
> Also, if that would be the case ... why isn't the text hidden as well in the
> first place(on the very first load)?

I'm not sure why it isn't hidden on first load.  Bryan, how would you like the box under "Block cookies and site data" in the Cookies and Site Data section to behave when "Accept cookies and site data" is checked?

Comment 6

[Johann Hofmann [:johannh]]

Yeah this is mostly up to definition by Bryan, but I agree that the initial state being inconsistent with what happens after you change the inputs is a bug (though not a severe one).

Comment 7

[:Gijs (away/busy until Mar 10)]

Going to reopen this based on comments #5 and 6.

Comment 8

[(no longer active)]

Note that the reason for this "bug" is that the way the UI is modeled doesn't match with our underlying cookie policy levels.

The UI pretends that we have two general modes of operation, the accept mode and the block mode, and the block mode has a number of states.

But under the hood, we only have a single axis here: we have a cookie policy that can take different values.  "accept all cookies" is just one possible cookie policy and is in no way special compared to any of the other cookie policies that are listed under the "block" radio button.

If we want to preserve what the user had selected in the block drop-down when they switch to the accept radio button, the only possible way to do that is to setup a shadow preference that carries the "old value" of the underlying preference when it's modified in the Cookies and Site Data section to Accept and use that shadow preference to restore the block state back to what it was before the switch later.  I don't recommend trying to go down that path while we have several ways of manipulating the network.cookie.cookieBehavior preference in our preferences UI though, since it's unclear how the shadow pref would need to be manipulated in those other cases.

Comment 9

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.

Comment 10

[Johann Hofmann [:johannh]]

This will get resolved by the new design in 65, which can be seen in bug 1461743. So we're not going to work on this bug.