Open Bug 12460 Opened 24 years ago Updated 8 months ago

Cannot select or edit or search generated content and alt text [GC]

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: elig, Unassigned)

References

(Blocks 6 open bugs,
URL
)

Details

(Keywords: helpwanted, testcase, Whiteboard: [Hixie-P3] When verifying, we must check all the DUPs!)

Attachments

(4 files)

Page with link to nonexisting image & ALT text
144 bytes, text/html
Details
Invalid image file that will display as a URL
143.79 KB, image/gif
Details
Testcase: Quotation marks generated with :before and :after on the "code" element.
261 bytes, text/html
Details
CSS to stop select cursor showing on generated content
84 bytes, text/css
dbaron
: review-
Details 
* TITLE/SUMMARY
I-Beam used for unselectable ALT text & invalid image URLs

* STEPS TO REPRODUCE
0) Launch Apprunner
1) Display either of the following two URLs:
 http://www.prometheus-music.com/gecko/selectalt.html (attached at test case)
 http://slip/projects/marvin/imaging/img-stress-gif/merr-01.gif (also attached)
2) Place the mouse pointer over the ALT text displayed, and attempt to select it.

* RESULT
 - What happened
Despite the fact that the cursor changes to an I-beam, the text cannot be
selected. Per Mac OS HI guidelines (p. 270), the I-beam is only to be displayed
while it's over text to imply selection and/or insertion ability.

 - What was expected

Either the cursor shouldn't be changed to one used to indicate selection ability,
or the text in question should be selectable.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (8.24.99 AM optimized build)
        Win32 Apprunner (8.24.99 AM optimized build [NT 4, Service Pack 3])
        Linux Apprunner (a recent optimized build w/ an invalid date string of
1999070614)

 - Doesn't Occur On
        N/A



* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Summary: I-Beam used for unselectable ALT text & invalid image URLs
Status: NEW → ASSIGNED
Target Milestone: M12
hmm is the mouse cursor me?? well i will take assignment until i can find out
As agreed with Beth, assigning myself as QA contact for all 'alt text' bugs...
Summary: I-Beam used for unselectable ALT text & invalid image URLs → broken img alt text is unselectable
The problem isn't that we have the wrong cursor, the problem is that we can't
select the alt text! Why can we not select the alt text?
the alt text for some reason has NO parent. i dont understand why not. i THINK
its generated content.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
ok the text is now selectable. please reverify.i have made a lot of changes in
this code and this looks fixed now. I cant be sure if i fixed this 100% please
reverify, thanks guys
Status: RESOLVED → REOPENED
Summary: broken img alt text is unselectable → Broken IMG alt text is not copied to clipboard
Resolution: FIXED → ---
I'm reopening this bug, because although we can select the alt text, it is not
being copied to the clipboard when you do Edit|Copy...
Whiteboard: [DOGFOOD]
14453 is related to this bug, I am marking that as a dup of this. Generated
content should be selectable, should be able to copy and paste. You should not
be able to edit it. Keeping this at M12, this should be fixed for beta
*** Bug 14453 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
We need to be consistent with how we provide selection of generated data. We
also need to be predictable from the user perspective. Generated data should be
selectable, and the user should also be able to copy it, the user should not be
able to edit it. Taking a quick stab at what is generated and the behavior
expected from the browser window, I came up with this list:
1. lists (UL, OL, DL, etc.) -- if a user selects several list items, and they
select copy, what should get dropped into the clipboard? The HTML? The visual
rendering such as numbers and bullets? Would the user expect to highlight the
bullets and have them copied? (I would suspect that the user would anticipate
copying the HTML so when they paste it is dropped in in the appropriate format),
but what if they paste into another application?
2. Alt text -- What happens if the user selects to edit the page -- should the
alt text be dropped in as part of the text stream? (No, it shouldn't -- it
should be part of the IMG dialog).
3. General Entity text -- If the user selects to edit the page -- what should
they see? Should they see the entity or the replaced text?
4. JavaScript generated -- If the user selects to edit the page -- what should
they see?

In any event, in all of the cases mentioned, in the browser window, the user
should be able to select the content and copy it.
Severity: minor → major
Priority: P3 → P2
Summary: Broken IMG alt text is not copied to clipboard → [DOGFOOD] Cannot select or edit generated content
Whiteboard: [DOGFOOD]
changing summary to better reflect the issue
Summary: [DOGFOOD] Cannot select or edit generated content → [DOGFOOD] [BETA]Cannot select or edit generated content
Whiteboard: [PDT-]
Definitely need this for Beta, but not dogfood. Putting on the PDT- radar.
*** Bug 19480 has been marked as a duplicate of this bug. ***
Adding myself to the Cc list.
Target Milestone: M12 → M13
moving to M13
Blocks: 20870
Summary: [DOGFOOD] [BETA]Cannot select or edit generated content → [BETA]Cannot select or edit generated content
Whiteboard: [PDT-]
updating summary fields
*** Bug 18453 has been marked as a duplicate of this bug. ***
Ian, when you verify this bug, could you please also take a look at bug #18453
--- or QA assign it to me when you're done verifying so that I can do so?

Thanks!
elig: Will do.
Target Milestone: M13
latering to m14 this will take a while to implement.
Target Milestone: M14
setting the milestone
*** Bug 25314 has been marked as a duplicate of this bug. ***
*** Bug 26135 has been marked as a duplicate of this bug. ***
*** Bug 17451 has been marked as a duplicate of this bug. ***
setting keyword
Keywords: beta1
Summary: [BETA]Cannot select or edit generated content → Cannot select or edit generated content
Whiteboard: [PDT+]
*** Bug 26168 has been marked as a duplicate of this bug. ***
this cannot be fixed due to a problem in CSS. we will fix this after m14 I will 
not put the beta at risk for this. vidur troy and I will be working with the 
style guys -aka pierre- to resolve this as soon as possible.
Target Milestone: M14 → M15
Depends on: 28057
please reevaluate i think its PDT-
Whiteboard: [PDT+]
Whiteboard: [PDT-]
*** Bug 28912 has been marked as a duplicate of this bug. ***
This bug also causes problems with selecting and copying text in view-source,
since view-source also uses generated content.

*** Bug 28816 has been marked as a duplicate of this bug. ***
Ian, when you verify this bug, would you be open to your choice of:

a) QA Assigning it to me in order to go through the duplicates and confirm that
they don't contain any remaining side issues.

b) Going through the duplicates and confirming that they don't contain any
remaining side issues. ;)

Thanks!

I don't mind which we do. It'll probably depend on when this is fixed -- if I'm
still at Uni then coursework may mean that I don't get enough time to go through
all the DUPs.
Whiteboard: [PDT-] → [PDT-] When verifying, we must check all the DUPs!
It sounds like this is mostly done... and hence probably not a blocker for the 
M15 stability checkpoint branch.  I'm pushing this to M16
Target Milestone: M15 → M16
yeah this is a dup of some bug I allready have.. cant find it . I will leave
this one open. the problem is that the iterator code does not work right yet for
generated content YET... ;)
Blocks: 36408
Blocks: 35044
Blocks: 13068
m17
Target Milestone: M16 → M17
With all this is blocking, why isn't it M16 beta2?
Keywords: beta1 → nsbeta2
beppe/mjudge - what is left to do here?  Is what is done so far enough for 
beta2?

sujay, since elig is out, can you check out the latest on the functionality here 
with the latest build? Thanks!
QA Contact: py8ieh=bugzilla → sujay
Whiteboard: [PDT-] When verifying, we must check all the DUPs! → [NEED INFO][PDT-] When verifying, we must check all the DUPs!
I just tried this using 5/11 build and I was able to select
the text, but as Beth mentioned...can't Copy it...
Whiteboard: [NEED INFO][PDT-] When verifying, we must check all the DUPs! → [nsbeta2+] 6/1 When verifying, we must check all the DUPs!
[nsbeta2+] will take fix by 6/1
m16
Target Milestone: M17 → M16
moving this off beta2 list, the current model being used to generate the view 
source file inhibits the ability to select portions of the file. Mike devoted 
several weeks at trying to resolve the issues for this. What needs to happen, is 
for the current model to change from its current method to a method that uses 
plaintext for example. In the current state, even if the user is able to 
select the content, they will not be able to perform functions such as 
copy/paste. The work-around for the user is to make a local copy and display the 
source either in the html edit mode in composer or through another plaintext 
editor. Moving to m20, setting as an rfe
Severity: major → enhancement
Keywords: nsbeta2
Priority: P2 → P3
Summary: Cannot select or edit generated content → [RFE]Cannot select or edit generated content
Whiteboard: [nsbeta2+] 6/1 When verifying, we must check all the DUPs! → When verifying, we must check all the DUPs!
Target Milestone: M16 → M20
moving to future milestone
Assignee: mjudge → beppe
Status: ASSIGNED → NEW
Target Milestone: M20 → Future
moving back to previous owner
Assignee: beppe → mjudge
No longer blocks: 20870
adding help wanted to the keywords
Keywords: helpwanted
Summary: [RFE]Cannot select or edit generated content → [RFE]Cannot select or edit or search generated content [GC]
Blocks: 57722
Whiteboard: When verifying, we must check all the DUPs! → [Hixie-P3] When verifying, we must check all the DUPs!
I thought I'd poke at this. Two problems I've run into so far:

1)  Selecting only works if stuff can be QIed to an nsIDOMNode.  Some generated
    content is associated with an nsAttributeContent, which does not implement
    nsIDOMNode.
2)  The text frames that come from nsTextNode content (eg strings in the
    "content" css property) never get HandlePress called on them when clicked
    (thus strongly suggesting that the proper events are simply never
    dispatched to them).
Summary: [RFE]Cannot select or edit or search generated content [GC] → [RFE] Cannot select or edit or search generated content and alt text [GC]
*** Bug 147801 has been marked as a duplicate of this bug. ***
BTW this is IMHO bug, not enhancement. If you agree, change please severity.
Keywords: testcase
Summary: [RFE] Cannot select or edit or search generated content and alt text [GC] → Cannot select or edit or search generated content and alt text [GC]
The following blog provides another example of this and may be helpful as a
testcase:
http://www.holovaty.com/blog/archive/2002/12/20/0454
Who should the owner be for this bug?  This is a usability issue for chatzilla.
 If anyone can provide a pointer of where to start, I might be able to look into
it.  We see the issue with regards to CSS generated content.  For example our
nicks look like "<nick>" where the angle brackets are added via css.  When you
try to select it to copy, you only get "nick".
Blocks: 223766
first, some people (glazou) think generated content should NOT be selectable.  
I happen to disagree, but in any case....

There are a few issues here.  First, the code at
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsFrame.cpp#1206
explicitly sets generated content not selectable.  I seem to recall that when I
took that out there were still issues with it.  That was partially because I was
testing on a page that used attr() and nsAttributeContent does not implement
nsIDOMNode (which selection needs).  That's covered by bug 214013

I suspect that selection relies on GetContentAndOffsetsFromPoint() doing
something reasonable.  See
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsFrame.cpp#1989. 
It's interesting to me that we no longer skip anonymous nodes there....
Generated content is, in the end, another form of anonymous content (in our
implementation) .  In any case, this may need fixing.

On the bright side,
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#1950
(nsTextFrame::GetContentAndOffsetsForSelection) seems to know something about
generated content.

Finally, once the above issues are addressed, there may be further bugs just
because selection is represented by DOM ranges and generated content is not
present in the DOM....

Hope that helps.
Is this related to the situation I just found:

    Mozilla Mail (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016)
    generates a "relaying denied" error pop-up from which I can't select and copy
    the message text, and put it into an email message to my sysadmin.

    My system:  RedHat 9, running the vendor-supplied XFree86 4 and KDE.

Being able to copy error-message text into messages to your sysadmin is a
*necessary* functionality, no matter *what* some people think about generated
content not being selectable.

Carlie J. Coats, Jr.                        carlie.coats@baronams.com
Environmental Modeling Center                    phone: (919)248-9241
Baron Advanced Meteorological Systems              fax: (919)248-9245
3021 Cornwallis Road                                 P. O. Box 110064
Research Triangle Park, N. C.  27709-5064                         USA

No, not related.
*** Bug 232361 has been marked as a duplicate of this bug. ***
The generated content should be selectable, or it could be a (hidden) pref.
Users will not understand why can't they select a text string clearly displayed
in the page, when everything else works.
*** Bug 243648 has been marked as a duplicate of this bug. ***
 Boris Zbarsky Wrote: 
    Finally, once the above issues are addressed, there may be further bugs just
because selection is represented by DOM ranges and generated content is not
present in the DOM....

Perhaps part of the solution would be to put generated text into the DOM with
something around it to indicated that it is generated and not 'real'?
In reply to comment #58 (the last comment), Samuel's suggestion about adding the
elements to the DOM but marking them as not real sounds somewhat similiar to
something I read in the W3 specs.

You can read about it here:
http://www.w3.org/TR/CSS21/selector.html#first-line-pseudo)
It describes a suggested method for handling pseudo elements in the browser.

An ordinary HTML paragraph . . . might be "rewritten" by user agents to include
the fictional tag sequence for :first-line. This fictional tag sequence helps to
show how properties are inherited.
<see url for example(s)>
If a pseudo-element breaks up a real element, the desired effect can often be
described by a fictional tag sequence that closes and then re-opens the element.
Thus, if we mark up the previous paragraph with a SPAN element:
<see url for example(s)>
A UA should act as if the fictional start tag of the first-line pseudo-element
is just inside the innermost enclosing block-level element. (Since CSS1 and CSS2
were silent on this case, authors should not rely on this behavior.) Here is an
example. The fictional tag sequence for
<see url for example(s)>

I don't know if this helps or not.
*** Bug 245491 has been marked as a duplicate of this bug. ***
*** Bug 246562 has been marked as a duplicate of this bug. ***
I'd still like to see this fixed!  If anyone wants to look at this, the code
referred to in comment 52 has had a lot of bitrot in the past 18 months.
The line in nsFrame::IsSelectable, where generated content is explicitly not
selected, is now at
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsFrame.cpp#1183
The line in nsFrame::GetContentAndOffsetsFromPoint where we skip generated
frames is http://lxr.mozilla.org/seamonkey/source/layout/generic/nsFrame.cpp#1889

Just a note: With the ALT text testcase, I cannot select the text if I start the
selection within the text.  But if I start the selection outside the image
element (the cursor is still an arrow) I can select, copy, and then paste the
text.  I imagine the code in nsFrame::IsSelectable is responsible for that, but
would probably have other ill effects if it was changed.

I am seriously considering learning C++ one of these days!

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-CA; rv:1.7.5) Gecko/20041107 Firefox/1.0
Would the suggestions from Comments #58 and Comment #59 be a viable solution to
take care of it not currently being a part of the DOM?
*** Bug 283494 has been marked as a duplicate of this bug. ***
Is there any progress on this bug? As mentioned in comment 63, some things that
were previously stopping this bug from being fixed have now been fixed /
changed. Bzbarsky, is there any chance of this bug being fixed, or are there
still problems which seem to be / are blocking this bug?
*** Bug 286061 has been marked as a duplicate of this bug. ***
Assignee: mjudge → selection
QA Contact: sujay
*** Bug 289802 has been marked as a duplicate of this bug. ***
*** Bug 296728 has been marked as a duplicate of this bug. ***
*** Bug 299830 has been marked as a duplicate of this bug. ***
*** Bug 302990 has been marked as a duplicate of this bug. ***
Opened: 1999-08-25 10:44 PDT
Any chance to see this bug fixed in the next ten year or so?
Is handling a DOM tree overlay for pseudo elements that difficult?
Blocks: 87673
*** Bug 311799 has been marked as a duplicate of this bug. ***
*** Bug 311905 has been marked as a duplicate of this bug. ***
*** Bug 312090 has been marked as a duplicate of this bug. ***
*** Bug 261654 has been marked as a duplicate of this bug. ***
* TITLE
found 2 additional bugs which fit into generated content problem

* SUMMARY
1. :first-letter won't work, if the first letter is a tag, i. e.
* STEPS TO REPRODUCE
------------
p:first-letter{font:40px} <-- in stylesheet
<p><img src"foobar">text</p>
------------
* RESULT
the first letter of "text" stays unchanged, instead of being bigger than normal.


* SUMMARY
2. :first-letter is buggy, if the first letter is a number and you have
additional positioning, i. e.

* STEPS TO REPRODUCE
------------
p:first-letter{font:40px;bottom:20px;} <-- in stylesheet
<p>123 456 789</p>
------------
* RESULT
the first number should be positioned 20px higher, but nothing happens.


* CONFIGURATIONS TESTED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006
Firefox/1.4.1 - Build ID: 2005100614
to get things rollin' i tried to change the fields priority, severity and target milestone, but it seems that only some people are allowed to do it :-(
it's just a shame that this bug exists more than 6 years and it's rated "enhancement"!
it's over time this bug gets done!!!
the future [target milestone] is NOW!
thx
ps: sorry for my harsh words ... i'll try to calm down a bit
*** Bug 274592 has been marked as a duplicate of this bug. ***
*** Bug 316591 has been marked as a duplicate of this bug. ***
*** Bug 317268 has been marked as a duplicate of this bug. ***
Blocks: 82676
As a fix to enable selecting generated content seems a way off why not stop the select cursor appearing for now?
Comment on attachment 228537 [details]
CSS to stop select cursor showing on generated content

I think this would make the style system do a lot more work when testing to see if it needs to generated :before and :after pseudo-elements.

Fixing this ought to be a one line fix in nsTextFrame::GetCursor (checking for NS_FRAME_GENERATED_CONTENT or whatever it's called).
Attachment #228537 - Flags: review-
*** Bug 72734 has been marked as a duplicate of this bug. ***
Note that bug 357957 is proposing removing some code that *might* be useful for fixing this bug, so anybody who works on this bug should see if it actually is useful and decide whether to restore it or replace it.
Bug, not enhancement.
Severity: enhancement → normal
There's an issue that is probably related to this bug report:

Here's the test case: http://daniel-faber.de/_files/mozilla-selection-of-generated-content.html
The x in front of each line is generated content.  When I select text in this page, sometimes the x' get highlighted and sometimes not.  It seems to depend on the path I move the mouse pointer.

Here is a screenshot: http://daniel-faber.de/_files/mozilla-selection-of-generated-content.png
It's three times the second section of my test case.  The red arrow shows the path of the mouse pointer while pressing the left mouse button.

When the Firefox window loses the focus, the highlighted area sometimes changes!

The selected text for copy to clipboard is always the same and does not include the generated content, it's just the inconsistent highlighting that bothers me.

I'm using Firefox 3 on Kubuntu 8.04.  Should I open a separate bug for this issue or do you think this comment is enought?
(In reply to comment #89)
> I'm using Firefox 3 on Kubuntu 8.04.  Should I open a separate bug for this
> issue or do you think this comment is enought?

There's Bug 394867 already.
Assignee: selection → nobody
QA Contact: selection
Blocks: 474971
Blocks: 424628
Could we get a status update on this bug? Anything stopping this from getting fixed? 10 years since this bug was filed, it has still seen no work at all...
Is there no work-around for this? I am trying to simply display the ID of a heading when hovered over, so that the user can select the bookmark anchor.

I.e. `h2[id]:hover:after {content: " #" attr(id);}`
Blocks: 394867
Blocks: 549150
Problem occurs in Firefox... isdraggable is still set to true because it appears to be for all images, but the cursor is set for the text underneath.  I will try to find a file that does one or the other when I get time.
I think in the file https://hg.mozilla.org/mozilla-central/file/aacac6efbbd4/layout/generic/nsImageFrame.cpp the alt text is added to the image frame. 

the function BuildDisplayList at the if block "if (!imageOK || !haveSize)" (line 1231) should probably set it to not draggable.  The getDraggable function line 828 in https://hg.mozilla.org/mozilla-central/file/aacac6efbbd4/content/html/content/src/nsGenericHTMLElement.cpp checks the nsGkAtoms::draggable to see if element can be dragged, so maybe that needs to be set to false, but I'm unsure.
I tried Joseph's suggestion by doing the change below, but that didn't result in any user-visible change. (Disclaimer: totally unfamiliar with layout code).

diff --git a/layout/generic/nsImageFrame.cpp b/layout/generic/nsImageFrame.cpp
--- a/layout/generic/nsImageFrame.cpp
+++ b/layout/generic/nsImageFrame.cpp
@@ -65,16 +65,17 @@
 #include "nsNetUtil.h"
 #include "nsHTMLContainerFrame.h"
 #include "prprf.h"
 #include "nsIFontMetrics.h"
 #include "nsCSSRendering.h"
 #include "nsILink.h"
 #include "nsIDOMHTMLAnchorElement.h"
 #include "nsIDOMHTMLImageElement.h"
+#include "nsGenericHTMLElement.h"
 #include "nsIDeviceContext.h"
 #include "nsINameSpaceManager.h"
 #include "nsTextFragment.h"
 #include "nsIDOMHTMLMapElement.h"
 #include "nsImageMapUtils.h"
 #include "nsIScriptSecurityManager.h"
 #ifdef ACCESSIBILITY
 #include "nsIAccessibilityService.h"
@@ -1226,16 +1227,17 @@ nsImageFrame::BuildDisplayList(nsDisplay
       currentRequest->GetImageStatus(&imageStatus);
     if (imageStatus & imgIRequest::STATUS_SIZE_AVAILABLE)
       haveSize = PR_TRUE;
 
     // We should never have the size and not have an image container
     NS_ABORT_IF_FALSE(!haveSize || imgCon, "Have size but not container?");
 
     if (!imageOK || !haveSize) {
+      nsGenericHTMLElement::FromContent(mContent)->SetDraggable(PR_FALSE);
       // No image yet, or image load failed. Draw the alt-text and an icon
       // indicating the status
       rv = aLists.Content()->AppendNewToTop(new (aBuilder)
           nsDisplayGeneric(aBuilder, this, PaintAltFeedback, "AltFeedback",
                            nsDisplayItem::TYPE_ALT_FEEDBACK));
       NS_ENSURE_SUCCESS(rv, rv);
     }
     else {
more than 12 years old bug. Maybe the Chosen One, who'd once fix it was already born and now he's somewhere at kindergarten.
Or maybe not and we'll have to wait until the next century...
(Stunning that this bug is still open after 12 years.)

As the generated content is transferred to screen readers (since Firefox 4 [1]) this should be accessible to users who want to copy and paste that text. It can contain important information like the format of a linked file[2] so I don’t see where the difference is.

[1] http://twitter.com/MarcoZehe/status/146175210066948096
[2] http://jsfiddle.net/yatil/Yft93/
I have the same problem.
It's with an userstyle.
Screenshot and code here :
<a href="http://forum.userstyles.org/discussion/30179/the-content-added-with-the-selector-after-cant-be-selected-and-copy-#Item_1">The content added with the selector &quot;:after&quot; can't be selected and copy ?</a>

A solution after all these tears ?
;-)
No solutions???
Blocks: 758580
Earlier, I asked bz on irc (#developers) about this.  His basic response
are as follows:  

bz	This stuff is complicated
bz_sleep	Word of advice. Right now we represent selections as DOM ranges.
bz_sleep	The basic issue with anonymous content is you can't have a range partially in it and partially in normal content...
bz_sleep	Which is why this bug is still open.
ewong	oh
bz_sleep	So you either have to change how ranges behave.
bz_sleep	Or change how the selection is represented internally.
bz_sleep	(or both)

fyi to whoever is interested in fixing this.
Target Milestone: Future → 1.4 S4 (28mar)
Target Milestone: 1.4 S4 (28mar) → Future
This is probably going to need to be optional per `content:` value: some, like the generated content for <q>, ought to be copyable and searchable. Others, like the generated content for <wbr> or several of the examples on http://viget.com/inspire/css-generated-content are presentational and shouldn't be copied or interfere with searches.
Blocks: 1108608
As a temporary solution, the mouse cursor should at least be changed to indicate that text selection isn’t possible.
See Also: → 1296261

Just to be clear, since my bug 1393633 was resolved as a duplicate of this one, and the bug title of this bug doesn't mention the same issue (though this could be related):

The current title of this bug is: "Cannot select or edit or search generated content and alt text [GC]". If I understand correctly, the user tries to select or search generated content. But in bug 1393633, I'm not trying to select generated content. It happens that the selection starts over generated content or just after generated content (near the boundary), but I just try to select normal text that follows this generated content, and this does not work.

FWIW, the searching part of this was fixed in bug 1627643.

No longer blocks: 1096071
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.