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

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

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.

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

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

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

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.

changing summary to better reflect the issue

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.

moving to M13

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.

latering to m14 this will take a while to implement.

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

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

please reevaluate i think its 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.

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

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... ;)

m17

With all this is blocking, why isn't it M16 beta2?

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!

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

[nsbeta2+] will take fix by 6/1

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

moving to future milestone

moving back to previous owner

adding help wanted to the keywords

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

*** Bug 147801 has been marked as a duplicate of this bug. ***

BTW this is IMHO bug, not enhancement. If you agree, change please severity.

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

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

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

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

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

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

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.

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

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???

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.

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.

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