The default bug view has changed. See this FAQ.

SVG Text Selection Not Supported

RESOLVED FIXED in mozilla1.9.2a1

Status

()

Core
SVG
RESOLVED FIXED
12 years ago
4 years ago

People

(Reporter: Jeff Schiller, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.9.2a1
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Input], URL)

Attachments

(2 obsolete attachments)

(Reporter)

Description

12 years ago
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).
(Reporter)

Comment 1

12 years ago
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.

Comment 2

12 years ago
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?

Comment 3

12 years ago
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. ***

Comment 5

12 years ago
*** Bug 311889 has been marked as a duplicate of this bug. ***
*** Bug 330038 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Blocks: 330046

Updated

11 years ago
Blocks: 330045

Comment 7

10 years ago
please note webkit and opera both have reasonable implementations
Any chance of getting this marked "wanted" for FF.next?
(Reporter)

Updated

9 years ago
Duplicate of this bug: 436645
(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 [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.

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

[1] http://www.svgbasics.com/simple_text.html
[2] http://groups.google.com/group/mozilla.dev.tech.svg/
[3] http://www.w3.org/TR/REC-xml/#sec-white-space

Comment 11

9 years ago
Running 3.0.1 Win, I can confirm this bug. It would be brilliant to have support for this.

Comment 12

8 years ago
Bug confirmed on Linux (i.e. Fedora 9)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) 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

Updated

8 years ago
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:1.9.0.13) 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:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Hopefully someone has the rights to update the "Platform".

Updated

8 years ago
OS: Windows 2000 → All
Hardware: x86 → All
Assignee: general → nobody
QA Contact: ian → general
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

Updated

8 years ago
Blocks: 512501
And:

http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-styling-css-06-b.html
Shouldn't this block bug 86194?
I don't really see the point, but okay.
Blocks: 86194

Updated

7 years ago
Duplicate of this bug: 540963
Duplicate of this bug: 571792
Whiteboard: [Input]

Comment 20

7 years ago
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.
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?

Comment 22

7 years ago
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.
Attachment #477445 - Attachment is obsolete: true
Attachment #477445 - Flags: feedback?(roc)

Comment 23

7 years ago
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.

Updated

7 years ago
Assignee: nobody → taken.spc

Comment 24

6 years ago
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... ;-)

Comment 25

6 years ago
Patches are always welcome ;-) This bug even has an incomplete patch from which to start.
Depends on: 655877

Updated

5 years ago
Duplicate of this bug: 747662
Depends on: 839955

Comment 27

4 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 30

4 years ago
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

Comment 31

4 years ago
(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

Updated

4 years ago
Assignee: taken.spc → nobody

Updated

4 years ago
Attachment #479340 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.