Copying data coming from a private browsing mode is omitted from the clipboard history
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox142 | --- | wontfix |
| firefox143 | --- | wontfix |
| firefox144 | --- | wontfix |
| firefox145 | --- | wontfix |
People
(Reporter: y.firefox, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Arch Linux
KDE
Bisected with mozregression, affected release version 142.
https://bugzilla.mozilla.org/show_bug.cgi?id=1701974 causes a regression.
Any text copied from a private window is not saved in the clipboard history, not just passwords, this breaks using private windows.
This is caused by the patch setting x-kde-passwordManagerHint for all private window data instead of just passwords.
Please revert https://hg-edge.mozilla.org/integration/autoland/rev/fb0fb62e1664496a22892517ae235cc079a9f163
Ref to the corresponding kde bug: https://bugs.kde.org/show_bug.cgi?id=508571
Updated•2 months ago
|
Comment 2•2 months ago
•
|
||
We apparently set the flag isPrivateData to true for both passwords and all data coming from private browsing mode. We must already have this same behavior on other platforms (Windows/macOS), so this just extended it to KDE.
Updated•2 months ago
|
Comment 3•2 months ago
|
||
Set release status flags based on info from the regressing bug 1701974
Comment 4•2 months ago
|
||
This really isn't platform specific, I think. The clipboard history and managers are probably just more visible to Linux users.
Updated•2 months ago
|
Comment 5•2 months ago
•
|
||
Hey Tom, I am not sure I see the rationale of this being S2 based on your comments. Would you mind checking again, or help elaborate on it? (Also CC @edgar).
In addition, regardless of the severity label, this is still an obvious behavior change from what we had before. Do you already have a plan in mind for how we should handle it going forward?
Comment 6•2 months ago
|
||
The bug is marked as tracked for firefox143 (beta) and tracked for firefox144 (nightly). However, the bug still isn't assigned.
:hsinyi, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Comment 7•2 months ago
|
||
Hey Tom, I am not sure I see the rationale of this being S2 based on your comments. Would you mind checking again, or help elaborate on it? (Also CC @edgar).
Do you think S2 is too low or too high? I would probably call it S3.
In addition, regardless of the severity label, this is still an obvious behavior change from what we had before. Do you already have a plan in mind for how we should handle it going forward?
We need to decide if we want to support the use case of allowing clipboard history for private browsing mode while not allowing it for passwords. I am not the right person to make that call. Changing this could/would change the behavior on other platforms like Windows, where we don't save the clipboard history either.
I think what I could do, is add a pref that makes this new behavior on Linux/KDE toggle-able.
Windows already has a pref for this:
https://searchfox.org/firefox-main/source/modules/libpref/init/StaticPrefList.yaml#2161
It can easily be extended to Linux/KDE.
I agree that in the long run, passwords and private browsing should be treated differently.
Comment 9•2 months ago
|
||
See bug 1988460 for the new pref.
Comment 10•2 months ago
|
||
Set release status flags based on info from the regressing bug 1701974
Comment 11•2 months ago
|
||
[Tracking Requested - why for this release]: With another review in the team meeting, we suggested to move forward with closing this as invalid, because this is a change by design that we extended the behavior from other platforms (like Windows, MacOS) to Linux/KDE.
I filed bug 1988878 to track comment 7.
Comment 12•2 months ago
|
||
[Tracking Requested - why for this release]: With another review in the team meeting, we suggested to move forward with closing this as invalid, because this is a change by design that we extended the behavior from other platforms (like Windows, MacOS) to Linux/KDE.
I filed bug 1988878 to track comment 7.
(oops, sorry for the comment duplicates)
Updated•2 months ago
|
Updated•2 months ago
|
Description
•