User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:18.104.22.168) Gecko/20090327 Camino/1.6.7 (like Firefox/22.214.171.124pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:126.96.36.199) Gecko/20090327 Camino/1.6.7 (like Firefox/188.8.131.52pre) After highlighting formatted text in the browser window and copying to the clipboard, the text on the clipboard contains carriage-return (^M) characters. Firefox, Safari don't put carriage-returns on the clipboard in this same scenario. When saving the HTML source from the same page using Camino, the same text does not have the ^M characters in it. In general, depending where you're pasting it, this whole thing can be an annoyance (but I reckon there's some case where it could be a bigger problem than just an annoyance). Reproducible: Always Steps to Reproduce: 1. On an HTML page, highlight a chunk of text containing multiple lines/paragaphs 2. CMD+C 3. at a shell prompt, type "pbpaste | cat -vet" Actual Results: The text contains ^M (carriage-return) characters Expected Results: The text should only contain line-feeds - no carriage-returns. Performing the same steps with another browser does not result in the superfluous ^M characters appearing. There is no workaround within Camino as far as I can tell.
I see identical output from Safari 3 and Camino 2 when copying the paragraph above ("After highlighting") and running the STR.
I just installed the Camino 2 beta (2.03b) and it doesn't behave like the stable version (1.6.7). The problem described above is apparently just in version 1.6.7.
WFM then, unless someone wants to track down the dup.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Should I not submit bug reports for the stable version? It works in beta 2 but I assumed 1.6.7 was still getting bug fixes.
Anything that's caused by Gecko is unlikely to be fixed (barring serious, reproducible crashes or security holes), while bugs caused by Camino code are still being fixed in 1.6.x (depending on the severity of the problem and scope of the fix). Unfortunately, most people don't know where the boundary is between those two parts of code, and we wouldn't expect them to, so it's hard for them to know what types of bugs are still "useful" to file and which ones we'll triage to WFM. Definitely keep reporting any crashes or hangs (though not all of them may be fixable); for other types of bugs, it's harder to say. If something doesn't work in 1.6.7 but does work in 2.0b3 and isn't something you'd consider a serious problem or significant breakage, there's a greater likelihood we'll just close it WFM (you can look at the 1.6.x Release Notes to get an idea of the kinds of fixes we have taken).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.