Closed Bug 292498 Opened 15 years ago Closed 7 years ago

SVG Text Selection Not Supported


(Core :: SVG, defect)

Not set





(Reporter: codedread, Unassigned)




(Whiteboard: [Input])


(2 obsolete files)

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:

I'm opening this bug to track that capability.  I also recommend that the 
Mozilla SVG status page ( 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  

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: :
"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. ***
Blocks: 330046
Blocks: 330045
please note webkit and opera both have reasonable implementations
Any chance of getting this marked "wanted" for
Duplicate of this bug: 436645
(In reply to comment #1)
> One update:  I played around with it a little on the two examples at 

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 group [2], would be most pleasant! ;-) Or am I missing something?

In the first sample [1] (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 [3] 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.

Firefox2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080404 Firefox/
Firefox3 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre

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: 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
Flags: wanted1.9.2+
Target Milestone: --- → mozilla1.9.2a1
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: 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: Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Hopefully someone has the rights to update the "Platform".
OS: Windows 2000 → All
Hardware: x86 → All
Assignee: general → nobody
QA Contact: ian → general
Blocks: svg11tests
Shouldn't this block bug 86194?
I don't really see the point, but okay.
Blocks: useragent
Duplicate of this bug: 540963
Duplicate of this bug: 571792
Whiteboard: [Input]
Attached patch WIP patch (obsolete) — Splinter Review
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:

* 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.

* 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...

* |selectSubString| is not implemented.
Attachment #477445 - Flags: feedback?(roc)
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?
Attached patch WIP patch 2 (obsolete) — Splinter Review
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.
Attachment #477445 - Attachment is obsolete: true
Attachment #477445 - Flags: feedback?(roc)
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.
Assignee: nobody → taken.spc
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.
Duplicate of this bug: 747662
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.
Closed: 7 years ago
Resolution: --- → FIXED
It is required setting svg.text.css-frames.enabled = true to select text in Nightly25.0a1.
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.
> 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.
Assignee: taken.spc → nobody
Attachment #479340 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.