User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050430 Firefox/1.0+ The SVG 1.1 Full specification clearly states that all conforming SVG viewers support text selection and copy: http://www.w3.org/TR/SVG/text.html#TextSelection I'm opening this bug to track that capability. I also recommend that the Mozilla SVG status page (http://www.mozilla.org/projects/svg/status.html) be updated with a line item in the Text Module called "Text Selection" with the W3C link being the afore-mentioned spec link. Reproducible: Always Steps to Reproduce: 1. create a SVG text element 2. view it in Mozilla+SVG browser 3. grumble as you see that you cannot select the text ;) Actual Results: You cannot select the text ;) Expected Results: Allow the user to select the text (even text rendered on a path) I don't know if it bothers anyone if I say this or not, but ASV allows this (if you are curious about how it is implemented).
One update: I played around with it a little on the two examples at http://www.svgbasics.com/simple_text.html. For the first text example, if I click and hold the mouse button down and then move up or down, the first text element ("It was the best of times") becomes highlighted and I can then copy that text. However, what is actually copied is only a portion of that element ("It was the"). I cannot select text from the second element, nor can I change what text is highlighted in the first element. The second example, I can select the first text element ("It was the best of times") and when I copy, it actually copies the entire contents properly. However, I am still not able to change what text is selected or select the second element ("It was the worst of times."). This seems to indicate that text selection is not simply "unimplemented" but it is being worked on and that it is currently broken.
Text selection is actually severely broken. It probably uses different mechanism of mouse event handling than all other SVG elements implementations, because when the SVG picture contains some text and you click outside the text and drag the mouse it sometimes selects arbitrary pieces of text. Also it violates mentioned specification, that reads that only <text> element without bound mouse events can be selected. I would like to know how to disable text selection at all. Do you know any workarounds?
I've tried this in Deer Park Alpha with Windows XP and find similar results. Text can be selected in some cases but not all. There is never an I-beam cursor as there is over HTML text. One point to note is that in the first example, the text selection can be started in the first line but will not continue to the second line. This is okay since the two lines are separate <text> elements. In the second example, however, the two lines are each a <tspan> in just one <text> element. According to the SVG spec: http://www.w3.org/TR/SVG/text.html#TSpanElement : "Multi-line 'text' elements are possible by defining different 'tspan' elements for each line of text, with attributes x, y, dx and/or dy defining the position of each 'tspan'. (An advantage of such an approach is that users will be able to perform multi-line text selection.)" So in the second example the text selection should be able to continue from the first <tspan> to the second. This is also what the helpful tutorial on the page says ;)
*** Bug 310214 has been marked as a duplicate of this bug. ***
*** Bug 311889 has been marked as a duplicate of this bug. ***
*** Bug 330038 has been marked as a duplicate of this bug. ***
please note webkit and opera both have reasonable implementations
Any chance of getting this marked "wanted" for FF.next?
(In reply to comment #1) > One update: I played around with it a little on the two examples at > http://www.svgbasics.com/simple_text.html. Picking up from this one I've noticed there have been (in Firefox3) recent (although almost unnoticeable) improvements on this matter. Although text selection still seems far from complete, some information updates regarding improvements, on this bug report or on mozilla.dev.tech.svg group , would be most pleasant! ;-) Or am I missing something? In the first sample  (first SVG image), double clicking on the first sentence, copy (whether using Ctrl+C or the context menu) and pasting into a simple text editor gives (all double quotes artificially added): "It was the best of times" Initially the line break plus the double space characters stumbled me. After inspection, I realized it seems to be copying the source text contents (just like the source view of the SVG file). Double clicking in the second sentence gives expected output: "It was the worst of times." Triple clicking on the canvas - at least in Windows platform, selects a whole sentence (or paragraph, depending on the application) gives: " It was the best of times It was the worst of times. " Few thoughts: * IMHO, the current major caveat (withing this matter) is not displaying text selection (selected text bounding box and color change and/or other usual user interface paradigms); * Double/triple clicking copies source (with indenting/line breaks) text and not text displayed - a test case using xml:space  set to "preserve" will help figuring out if this is an issue or a feature; * Triple clicking seems to (erroneously) select CSS style information and markup indenting characters - a test case is needed to allow reproducing this behavior. Versions: Firefox2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080404 Firefox/22.214.171.124 Firefox3 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre  http://www.svgbasics.com/simple_text.html  http://groups.google.com/group/mozilla.dev.tech.svg/  http://www.w3.org/TR/REC-xml/#sec-white-space
Running 3.0.1 Win, I can confirm this bug. It would be brilliant to have support for this.
Bug confirmed on Linux (i.e. Fedora 9) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2008111217 Fedora/3.0.4-1.fc9 Firefox/3.0.4 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1
This is still marked as "Platform: x86 Windows 2000" when in fact this seems a non-platform-specific problem. I too can reproduce the problem on both Linux: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13 and on Windows: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Hopefully someone has the rights to update the "Platform".
This bug blocks us from passing the following tests from the W3C SVG 1.1 Full testsuite: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-tselect-02-f.html http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-text-tselect-01-b.html
Shouldn't this block bug 86194?
I don't really see the point, but okay.
Created attachment 477445 [details] [diff] [review] WIP patch This patch enables: * Drawing selection highlights (both of single and multiple) * Drawing search highlights Drawing highlights is actually drawing bounding boxes behind the contents # WebKit does something similar # Opera uses bounding boxes and fill and disables stroke for the selection. But this is incomplete. There are several issues: Selection * It's hard to select the last character. * No double/triple click selection (word/line selection). * Moving the selection by keyboard (shift + arrows) do not work. Implementing |PeekOffsetCharacter| and so on is needed. * No caret. Drawing * The colors of selections differ with HTML (e.g. the color of selections in inactive window and a hit in a search) * If an element has a thick stroke, the highlights will be invisible (stroke hides the highlights). Drawing only the bounding boxes causes this. If we use fill for highlighting, the ligatures will become a problem Anyway, drawing the highlight should be much better... DOM * |selectSubString| is not implemented.
This looks like a good start. I think you might want to factor out some of the code in nsTextFrame that computes selection colors and use it here. The code that tries to find a color that's different from the nearest background color should work here too. Is there anything specific you want feedback on?
Created attachment 479340 [details] [diff] [review] WIP patch 2 Another wip patch. * Highlighting colors are now same as HTML * Expanding/Collapsing a selection by a keyboard is work at some level * Selecting the text with xml:space="preserve" is now work Although, it definitely needs more work.
MOZ_SVG is going away in bug 585020. You should just add stuff as if it is always defined and not surround it with ifdef MOZ_SVG.
I'm trying to encourage some friends to start using SVG in their online applications, but missing support is something which two of them see as a key feature and don't like current Gecko status. So ma message to you is: people would really appreciate to have it working, even if the implementation would be incomplete or buggy a bit... ;-)
Patches are always welcome ;-) This bug even has an incomplete patch from which to start.
SVG is being used more and more often in HTML5 charting libraries. The inability to select values/labels is sub-great.
(In reply to Potch [:potch] from comment #27) > SVG is being used more and more often in HTML5 charting libraries. The > inability to select values/labels is sub-great. Hi Potch, this is being fixed in bug 655877 which has been making good progress.
SVG text should now be selectable, with bug 655877 and dependants landed.
It is required setting svg.text.css-frames.enabled = true to select text in Nightly25.0a1. http://hg.mozilla.org/mozilla-central/rev/c5ce065936fa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130629 Firefox/25.0 ID:20130629031116
(In reply to Alice0775 White from comment #30) > It is required setting svg.text.css-frames.enabled = true to select text in > Nightly25.0a1. > > http://hg.mozilla.org/mozilla-central/rev/c5ce065936fa > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130629 Firefox/25.0 > ID:20130629031116 The pref was flipped, true by default in the next nightly. https://hg.mozilla.org/mozilla-central/rev/3a23afb038a5