Open
Bug 12460
Opened 25 years ago
Updated 9 months ago
Cannot select or edit or search generated content and alt text [GC]
Categories
(Core :: DOM: Selection, defect, P3)
Core
DOM: Selection
Tracking
()
NEW
Future
People
(Reporter: elig, Unassigned)
References
(Blocks 6 open bugs, )
Details
(Keywords: helpwanted, testcase, Whiteboard: [Hixie-P3] When verifying, we must check all the DUPs!)
Attachments
(4 files)
* 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•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Summary: I-Beam used for unselectable ALT text & invalid image URLs
hmm is the mouse cursor me?? well i will take assignment until i can find out
Comment 4•25 years ago
|
||
As agreed with Beth, assigning myself as QA contact for all 'alt text' bugs...
Updated•25 years ago
|
Summary: I-Beam used for unselectable ALT text & invalid image URLs → broken img alt text is unselectable
Comment 5•25 years ago
|
||
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: 25 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
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Summary: broken img alt text is unselectable → Broken IMG alt text is not copied to clipboard
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 8•25 years ago
|
||
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•25 years ago
|
Whiteboard: [DOGFOOD]
Comment 9•25 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•25 years ago
|
||
*** Bug 14453 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Comment 11•25 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•25 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•25 years ago
|
||
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-]
Comment 13•25 years ago
|
||
Definitely need this for Beta, but not dogfood. Putting on the PDT- radar.
Comment 14•25 years ago
|
||
*** Bug 19480 has been marked as a duplicate of this bug. ***
Comment 15•25 years ago
|
||
Adding myself to the Cc list.
Updated•25 years ago
|
Target Milestone: M12 → M13
Comment 16•25 years ago
|
||
moving to M13
Updated•25 years ago
|
Summary: [DOGFOOD] [BETA]Cannot select or edit generated content → [BETA]Cannot select or edit generated content
Whiteboard: [PDT-]
Comment 17•25 years ago
|
||
updating summary fields
Comment 18•25 years ago
|
||
*** Bug 18453 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•25 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!
Comment 20•25 years ago
|
||
elig: Will do.
Comment 21•25 years ago
|
||
latering to m14 this will take a while to implement.
Updated•25 years ago
|
Target Milestone: M14
Comment 22•25 years ago
|
||
setting the milestone
Comment 23•25 years ago
|
||
*** Bug 25314 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
*** Bug 26135 has been marked as a duplicate of this bug. ***
Comment 25•25 years ago
|
||
*** Bug 17451 has been marked as a duplicate of this bug. ***
Comment 26•25 years ago
|
||
setting keyword
Keywords: beta1
Summary: [BETA]Cannot select or edit generated content → Cannot select or edit generated content
Comment 27•25 years ago
|
||
*** Bug 26168 has been marked as a duplicate of this bug. ***
Comment 28•25 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
Comment 30•25 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•25 years ago
|
||
*** Bug 28816 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 33•25 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!
Comment 34•25 years ago
|
||
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•25 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•25 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... ;)
Comment 38•25 years ago
|
||
With all this is blocking, why isn't it M16 beta2?
Comment 39•25 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•25 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•25 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•25 years ago
|
||
[nsbeta2+] will take fix by 6/1
Comment 43•25 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
Updated•24 years ago
|
Target Milestone: M20 → Future
Updated•24 years ago
|
Summary: [RFE]Cannot select or edit generated content → [RFE]Cannot select or edit or search generated content [GC]
Updated•23 years ago
|
Whiteboard: When verifying, we must check all the DUPs! → [Hixie-P3] When verifying, we must check all the DUPs!
Comment 47•23 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).
Updated•23 years ago
|
Summary: [RFE]Cannot select or edit or search generated content [GC] → [RFE] Cannot select or edit or search generated content and alt text [GC]
Comment 48•23 years ago
|
||
*** Bug 147801 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
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]
Comment 50•22 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•21 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".
Comment 52•21 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•21 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•21 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.
Comment 57•21 years ago
|
||
*** Bug 243648 has been marked as a duplicate of this bug. ***
Comment 58•21 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•21 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•21 years ago
|
||
*** Bug 245491 has been marked as a duplicate of this bug. ***
Comment 61•20 years ago
|
||
*** Bug 246562 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
Comment 63•20 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•20 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•20 years ago
|
||
*** Bug 283494 has been marked as a duplicate of this bug. ***
Comment 66•20 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•20 years ago
|
||
*** Bug 286061 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: mjudge → selection
QA Contact: sujay
Comment 68•20 years ago
|
||
*** Bug 289802 has been marked as a duplicate of this bug. ***
Comment 69•19 years ago
|
||
*** Bug 296728 has been marked as a duplicate of this bug. ***
Comment 70•19 years ago
|
||
*** Bug 299830 has been marked as a duplicate of this bug. ***
Comment 71•19 years ago
|
||
*** Bug 302990 has been marked as a duplicate of this bug. ***
Comment 72•19 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?
Comment 73•19 years ago
|
||
*** Bug 311799 has been marked as a duplicate of this bug. ***
Comment 74•19 years ago
|
||
*** Bug 311905 has been marked as a duplicate of this bug. ***
Comment 75•19 years ago
|
||
*** Bug 312090 has been marked as a duplicate of this bug. ***
Comment 76•19 years ago
|
||
*** Bug 261654 has been marked as a duplicate of this bug. ***
Comment 77•19 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•19 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
Comment 79•19 years ago
|
||
*** Bug 274592 has been marked as a duplicate of this bug. ***
Comment 80•19 years ago
|
||
*** Bug 316591 has been marked as a duplicate of this bug. ***
Comment 81•19 years ago
|
||
*** Bug 317268 has been marked as a duplicate of this bug. ***
Comment 82•18 years ago
|
||
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-
Comment 84•18 years ago
|
||
*** 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.
Comment 89•16 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•16 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.
Updated•16 years ago
|
Assignee: selection → nobody
QA Contact: selection
Comment 95•15 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...
Comment 97•15 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);}`
Comment 98•15 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•15 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.
Comment 100•14 years ago
|
||
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 {
Comment 102•13 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•13 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•13 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 ":after" can't be selected and copy ?</a>
A solution after all these tears ?
;-)
Comment 107•12 years ago
|
||
No solutions???
Comment 110•11 years ago
|
||
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•11 years ago
|
Target Milestone: 1.4 S4 (28mar) → Future
Comment 111•10 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.
Comment 116•9 years ago
|
||
As a temporary solution, the mouse cursor should at least be changed to indicate that text selection isn’t possible.
Comment 118•4 years ago
|
||
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.
Comment 119•4 years ago
|
||
FWIW, the searching part of this was fixed in bug 1627643.
Updated•2 years ago
|
Severity: normal → S3
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•