test_copypaste.xul fails when loaded as XHTML
Categories
(Core :: XUL, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: bdahl, Assigned: bdahl)
References
Details
Attachments
(1 file)
With the XUL as XHTML patch test_copypaste.xul starts failing.
This is because for XUL documents we force plain text selection.
The above branch was added in bug 888839, because copy/paste of alert dialogs wasn't carrying formatting of newlines across. However, with current Firefox alerts, if I remove the above special branch, dialogs with newlines still work as expected.
|
Assignee | |
Comment 1•5 years ago
|
||
Do you think we're fine to remove this special copy/paste behavior? If not, do you have an alternative way to keep the test passing in a post-XULDocument world?
|
||
Comment 2•5 years ago
|
||
Sorry, I'm late with this. Need to read also all of bug 723163
|
|
||
Comment 3•5 years ago
|
||
ok, and bug 888839 just added back something which bug 723163 removed.
The broader question is that how should copy-paste work in UI documents, when those are (X)HTML? Is that something we have considered? Or is it expected that all chrome (X)HTML is basically non-selectable, expect in special cases like alerts?
|
|
||
Comment 4•5 years ago
|
||
But still, XUL has had basically different copy-paste handling, so I guess that .xul test shouldn't be even loaded as xhtml.
|
|
Assignee | |
Comment 5•5 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #3)
ok, and bug 888839 just added back something which bug 723163 removed.
The broader question is that how should copy-paste work in UI documents, when those are (X)HTML? Is that something we have considered? Or is it expected that all chrome (X)HTML is basically non-selectable, expect in special cases like alerts?
Copy/paste should largely behave the way it did with XUL documents. It's up to the element if the copy/paste is enabled/disabled. The above bug starts failing because the formatting changes in XHTML vs XUL.
I looked back at bug 723163, which is about about:crashes copy/paste formatting being messed up. However, if I apply my patch with force plain text selection disabled, the about:crashes text still copy/pastes as expected with newlines and spaces.
I still have yet to find anywhere in the UI that relies on newlines being preserved. If there are any places, it seems we could instead change it to be white-space:pre or something. Do you know of anywhere that needs the XUL behavior, or are we fine to remove it?
|
|
||
Comment 6•5 years ago
|
||
I don't know whether xul needs that behavior, especially these days.
But if we change behavior, better to test this a bit.
Could we change the check from !htmlorxhtml to chromedoc?
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 7•5 years ago
|
||
The force text plain formatting of copy/paste with XUL documents doesn't
appear to be needed anywhere anymore.
Pushed by bdahl@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/159e92b813b6 Remove old XUL copy/paste behavior. r=smaug
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
Description
•