1192622 - Fennec converts newlines into spaces when copying selected text

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: Text Selection, defect)

Description

[Mindaugas <LA-MJ>]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.26 Safari/537.36

Steps to reproduce:

1. Try to copy formatted text with Firefox for Android from these URLs:
1) http://dpaste.com/1C9DSD2 (pre)
2) http://dpaste.com/1C9DSD2.txt (text/plain)
3) http://pastebin.com/M0c4weui (lines wrapped in <div>s)
2. Paste in a textarea somewhere.
3. Validate results by running `encodeURI($0.value)` in a debugging session.


Actual results:

Fennec loses new lines in cases #1 and #2. Versions stable (v39) through nightly (v42) are affected.


Expected results:

New lines should be preserved in all 3 cases. Tested OK in Chrome for Android.

Comment 1

[Mark Capella [:capella]]

Pruning some old bugs (part 2) either:
   ) obviated by new Core/Layout AccessibleCaret implementation in m-c and stable, targeted for 47.
   ) Or no longer being observable.

If you still see what you consider incorrect behaviour with the new version (nightly m-c v47.0a1), please file a new bug targeted there, and attach a test-case or example link to help things :-)


Specific note here: I don't see this in v44 (original text selection) nor in v47 (new AccessibleCarets).
Tested by copying and pasting into bugzilla textarea ...

Comment 2

[Mindaugas <LA-MJ>]

How exactly was WORKSFORME status decided? Have you submitted a form? Have you followed my advice to use remote debugging?

Because if you did it visually let me clear up this illusion for you:

http://i.imgur.com/8mnLtxs.png
http://i.imgur.com/FgQwtKU.png

And yes this is with Fennec nightly 47.

I don't see what is wrong with this bug, why create another one?
What kind of test-case or link is needed? Comment 1 already has links to the text I use

Comment 3

[Mark Capella [:capella]]

Awesome, thank you. Yes, while working through the backlog, I did the visual, and overlooked the technical difference here.

Comment 4

[Mark Capella [:capella]]

So what I see is, with your STR as follows:

1. Try to copy formatted text with Firefox for Android from these URLs:
1) http://dpaste.com/1C9DSD2 (pre)

You're not actually copying formatted text ... see [0] ... there are no newlines to copy to the clipboard.

If I copy the source text to a text area, key / manually introduce newlines then select all and COPY, the newlines are indeed copied (I fixed that back a bit in Bug 938563 - Select all + copy on textarea doesn't copy linebreaks).

Am I still missing something here?


[0] https://www.dropbox.com/s/ws7gcn55laay96j/bug1192622_sourceText.png?dl=0

Comment 5

[Mindaugas <LA-MJ>]

Well, I do not think HTML is important here seeing as it fails in plain text mode as well:
http://dpaste.com/1C9DSD2.txt

Not sure it's relevant but when I curl'ed this URL, the response contains lines separated by '\r\n'

Comment 6

[Mark Capella [:capella]]

That would be the raw source, vs. the rendered / displayed final text that is trying to be copied to the clipboard.

Comment 7

[Mindaugas <LA-MJ>]

That is not the point. The point is you cannot copy the text faithfully having opened http://dpaste.com/1C9DSD2.txt in Fennec.

The HTML view may or may not be wrong but why would that matter if the default HTML for a text/plain file shows the same behavior? There is nothing wrong with the generated HTML[1] so the problem must lie in the select-copy-paste logic. I remind you that Google Chrome handles all 3 URLs correctly.

[1] http://i.imgur.com/zmm6VhJ.png

Comment 8

[Mark Capella [:capella]]

Hmmmmm ... I'm actually getting the \n's copied for the case of [2] and [3], but not for the first case [1].

My Inspector tool shows that page as [1d]. That |softwrap| button setting seems interesting, but doesn't affect my results. 

Looking further ...

[1] https://www.dropbox.com/s/xlmkwvu02ii0nd3/bug1192622_1_PRE.png?dl=0
[1d] https://www.dropbox.com/s/8so3ifhnu69xe6c/bug1192622_1_PRE_INSPECT.png?dl=0

[2] https://www.dropbox.com/s/mc4lm3uxxwfo8vo/bug1192622_2_text-plain.png?dl=0
[3] https://www.dropbox.com/s/oqem21sbck31ft5/bug1192622_3_wrapped_div.png?dl=0

Comment 9

[Mindaugas <LA-MJ>]

I'm not exactly sure what I should glean from those screenshots. But I did test 
> 2) http://dpaste.com/1C9DSD2.txt (text/plain)
with Fennec 47 and found wrong behavior by the same method as in comment 2

Comment 10

[Mindaugas <LA-MJ>]

I've rechecked it again and found something interesting.

a) If I use |select all| button on http://dpaste.com/1C9DSD2.txt I get the correct behavior
b) if I manually relocate the selection markers I get the wrong behavior

Comment 11

[Mirko Brodesser (:mbrodesser-Igalia)]

Unfortunately the dpaste.com links are down, so it's hard to reproduce the issue.

Mindaugas, it's been a long time, but if you still remember, can you please attach test-cases to this issue?

Comment 12

[Mindaugas <LA-MJ>]

There was nothing special about those pastes, the content was identical to pastebin.com. They are limited to 1y, sure.

Aside from the fact that FF stable is v68 on Google Play and no longer actually debuggable, I could not reproduce the problem with it, nor with Nightly.