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

NEW
Unassigned

Status

()

Core
Selection
P3
normal
18 years ago
11 months ago

People

(Reporter: Eli Goldberg, Unassigned)

Tracking

(Blocks: 9 bugs, {helpwanted, testcase})

Trunk
Future
helpwanted, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments)

(Reporter)

Description

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

Comment 1

18 years ago
Created attachment 1384 [details]
Page with link to nonexisting image & ALT text
(Reporter)

Comment 2

18 years ago
Created attachment 1385 [details]
Invalid image file that will display as a URL
(Reporter)

Updated

18 years ago
Summary: I-Beam used for unselectable ALT text & invalid image URLs

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M12

Comment 3

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

Comment 6

18 years ago
the alt text for some reason has NO parent. i dont understand why not. i THINK
its generated content.

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

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

Updated

18 years ago
Whiteboard: [DOGFOOD]

Comment 9

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

Comment 10

18 years ago
*** Bug 14453 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Status: REOPENED → ASSIGNED

Comment 11

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

Updated

18 years ago
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]

Comment 12

18 years ago
changing summary to better reflect the issue

Updated

18 years ago
Summary: [DOGFOOD] Cannot select or edit generated content → [DOGFOOD] [BETA]Cannot select or edit generated content
Whiteboard: [PDT-]

Comment 13

18 years ago
Definitely need this for Beta, but not dogfood. Putting on the PDT- radar.

Comment 14

18 years ago
*** Bug 19480 has been marked as a duplicate of this bug. ***

Comment 15

18 years ago
Adding myself to the Cc list.

Updated

18 years ago
Target Milestone: M12 → M13

Comment 16

18 years ago
moving to M13

Updated

18 years ago
Blocks: 20870

Updated

18 years ago
Summary: [DOGFOOD] [BETA]Cannot select or edit generated content → [BETA]Cannot select or edit generated content
Whiteboard: [PDT-]

Comment 17

18 years ago
updating summary fields

Comment 18

18 years ago
*** Bug 18453 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 19

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

Updated

18 years ago
Target Milestone: M13

Comment 21

18 years ago
latering to m14 this will take a while to implement.

Updated

18 years ago
Target Milestone: M14

Comment 22

18 years ago
setting the milestone

Comment 23

18 years ago
*** Bug 25314 has been marked as a duplicate of this bug. ***

Comment 24

18 years ago
*** Bug 26135 has been marked as a duplicate of this bug. ***

Comment 25

18 years ago
*** Bug 17451 has been marked as a duplicate of this bug. ***

Comment 26

18 years ago
setting keyword
Keywords: beta1
Summary: [BETA]Cannot select or edit generated content → Cannot select or edit generated content

Updated

18 years ago
Whiteboard: [PDT+]

Comment 27

18 years ago
*** Bug 26168 has been marked as a duplicate of this bug. ***

Comment 28

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

Updated

18 years ago
Depends on: 28057

Comment 29

18 years ago
please reevaluate i think its PDT-
Whiteboard: [PDT+]

Updated

18 years ago
Whiteboard: [PDT-]

Comment 30

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

Comment 32

18 years ago
*** Bug 28816 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 33

18 years ago
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!

Comment 35

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

Comment 36

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

Updated

18 years ago
Blocks: 36408

Updated

18 years ago
Blocks: 35044

Updated

18 years ago
Blocks: 13068

Comment 37

18 years ago
m17
Target Milestone: M16 → M17

Comment 38

18 years ago
With all this is blocking, why isn't it M16 beta2?
Keywords: beta1 → nsbeta2

Comment 39

17 years ago
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!

Comment 40

17 years ago
I just tried this using 5/11 build and I was able to select
the text, but as Beth mentioned...can't Copy it...

Updated

17 years ago
Whiteboard: [NEED INFO][PDT-] When verifying, we must check all the DUPs! → [nsbeta2+] 6/1 When verifying, we must check all the DUPs!

Comment 41

17 years ago
[nsbeta2+] will take fix by 6/1

Comment 42

17 years ago
m16
Target Milestone: M17 → M16

Comment 43

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

Comment 44

17 years ago
moving to future milestone
Assignee: mjudge → beppe
Status: ASSIGNED → NEW

Updated

17 years ago
Target Milestone: M20 → Future

Comment 45

17 years ago
moving back to previous owner
Assignee: beppe → mjudge

Updated

17 years ago
No longer blocks: 20870

Comment 46

17 years ago
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]

Updated

16 years ago
Blocks: 57722
Whiteboard: When verifying, we must check all the DUPs! → [Hixie-P3] When verifying, we must check all the DUPs!

Comment 47

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

Comment 49

15 years ago
BTW this is IMHO bug, not enhancement. If you agree, change please severity.
Keywords: testcase

Updated

15 years ago
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]

Comment 50

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

Comment 51

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

Updated

14 years ago
Blocks: 223766

Comment 52

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

Comment 53

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

Comment 56

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

Comment 58

13 years ago
 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'?

Comment 59

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

Comment 60

13 years ago
*** Bug 245491 has been marked as a duplicate of this bug. ***
*** Bug 246562 has been marked as a duplicate of this bug. ***

Comment 62

13 years ago
Created attachment 154196 [details]
Testcase: Quotation marks generated with :before and :after on the "code" element.

Comment 63

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

Comment 64

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

Comment 65

13 years ago
*** Bug 283494 has been marked as a duplicate of this bug. ***

Comment 66

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

Comment 67

13 years ago
*** Bug 286061 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Assignee: mjudge → selection
QA Contact: sujay

Comment 68

13 years ago
*** Bug 289802 has been marked as a duplicate of this bug. ***
*** Bug 296728 has been marked as a duplicate of this bug. ***

Comment 70

12 years ago
*** Bug 299830 has been marked as a duplicate of this bug. ***
*** Bug 302990 has been marked as a duplicate of this bug. ***

Comment 72

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

Updated

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

Comment 77

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

Comment 78

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

Comment 80

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

Comment 81

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

Updated

12 years ago
Blocks: 82676

Comment 82

11 years ago
Created attachment 228537 [details]
CSS to stop select cursor showing on generated content

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.
Duplicate of this bug: 370027
Duplicate of this bug: 371150

Comment 88

11 years ago
Bug, not enhancement.
Severity: enhancement → normal

Comment 89

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

Comment 90

9 years ago
(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
Duplicate of this bug: 452847
Duplicate of this bug: 475493

Updated

9 years ago
Blocks: 474971
Duplicate of this bug: 460022

Updated

8 years ago
Duplicate of this bug: 490805

Updated

8 years ago
Blocks: 424628

Comment 95

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

Updated

8 years ago
Duplicate of this bug: 508543

Comment 97

8 years ago
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);}`

Updated

8 years ago
Blocks: 394867

Updated

8 years ago
Blocks: 549150

Comment 98

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

Comment 99

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

Updated

7 years ago
Duplicate of this bug: 625869

Comment 102

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

Comment 103

6 years ago
(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/

Comment 104

6 years ago
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 ?
;-)
Duplicate of this bug: 761079

Updated

5 years ago
Duplicate of this bug: 782082

Comment 107

5 years ago
No solutions???

Updated

5 years ago
Duplicate of this bug: 837506
Duplicate of this bug: 892250

Updated

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

Updated

4 years ago
Target Milestone: 1.4 S4 (28mar) → Future

Comment 111

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

Updated

3 years ago
Duplicate of this bug: 588716

Updated

3 years ago
Duplicate of this bug: 1096063

Updated

3 years ago
Duplicate of this bug: 1096069

Updated

3 years ago
Blocks: 1096071
Blocks: 1108608

Updated

2 years ago
Duplicate of this bug: 1216438

Comment 116

a year ago
As a temporary solution, the mouse cursor should at least be changed to indicate that text selection isn’t possible.

Updated

11 months ago
See Also: → bug 1296261
You need to log in before you can comment on or make changes to this bug.