Closed
Bug 16286
Opened 25 years ago
Closed 25 years ago
Assertion when selecting a text styled with pseudo content
Categories
(Core :: Layout, defect, P1)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: rbs, Assigned: mjudge)
Details
With today's tree, the code crash when the mouse is used to
select a text enclosed in quotes, where the quotes are
generated content.
Here is a test file that allows to easily reproduce the bug.
When selecting all of the text (excluding the quotes), the code
invariably crashes (on Win95).
<html>
<head>
<style>
b:before { content: open-quote; }
b:after { content: close-quote; }
</style>
</head>
<body>
<b>to crash, slowly select only the text up to here</b>
</body>
</html>
Mike, stack shows it's in the selection code. I remember we talked about this
once. I don't know if this is something you've worried about yet.
What we decided to do was to have the generated content nodes have a "parent"
content pointer and a "document" content pointer, but they're not really part of
the document model in that no content object points to the node
nsDebug::NotReached(const char * 0x0199ec20, const char * 0x0199ebf8, int 540)
line 297 + 13 bytes
nsRange::IsIncreasing(nsIDOMNode * 0x01bc5db8, int 0, nsIDOMNode * 0x01bc6d28,
int 0) line 540 + 21 bytes
nsRange::SetEnd(nsRange * const 0x01bbc748, nsIDOMNode * 0x01bc6d28, int 0) line
1001 + 49 bytes
ComparePoints(nsIDOMNode * 0x01bc5db8, int 0, nsIDOMNode * 0x01bc6d28, int 0)
line 96 + 20 bytes
nsDOMSelection::Extend(nsDOMSelection * const 0x01bada28, nsIDOMNode *
0x01bc6d28, int 0) line 3137 + 31 bytes
nsRangeList::TakeFocus(nsRangeList * const 0x01bad9c0, nsIContent * 0x01bc6d34,
unsigned int 0, unsigned int 0, int 1, int 0) line 1131
|
||
Comment 2•25 years ago
|
||
accepting/m11
|
||
Updated•25 years ago
|
Priority: P3 → P1
Summary: Crash when selecting a text styled with pseudo content → [CRASH] when selecting a text styled with pseudo content
|
|
||
Comment 3•25 years ago
|
||
this one is a doozy. The range code has NO WAY to tell the two nodes that
represent the quote marks apart. This is because they both appear to have the
same set of ancestors, at the same offsets. Even those these nodes are at
different locations they both show up at offset -1, an artificial value for
anonymous content. When the range code tries to determine if the start and end
points for the range are in the correct order, it gets into this impossible
situation: the nodes aren't the same, so one must be before or after the other.
But they both have the exact same chain of ancestors and offsets. There is no
way for the range code to deal with this. Selection needs to be modified to not
use range enopints that have one endpoint in some generated content but the other
endpoint not in that same generated content.
cc'ing mike
|
|
||
Updated•25 years ago
|
Assignee: jfrancis → kin
Status: ASSIGNED → NEW
|
||
Updated•25 years ago
|
Severity: normal → critical
|
|
||
Updated•25 years ago
|
Target Milestone: M11 → M12
|
|
||
Comment 5•25 years ago
|
||
moving to M12
Summary: [CRASH] when selecting a text styled with pseudo content → Assertion when selecting a text styled with pseudo content
Target Milestone: M12 → M13
Removing [CRASH] from summary since this is only an assertion in debug builds.
I checked in some code to fix bug #17989 that locks the selection anchor and
focus nodes into the same valid subtree when drag selecting. This prevents this
assertion from being thrown when dragging, but it is still a problem when using
the shift-click method to extend the selection.
I'm moving this bug to M13 when I should have time to revisit this issue.
|
|
||
Updated•25 years ago
|
Assignee: kin → mjudge
Status: ASSIGNED → NEW
|
|
||
Comment 7•25 years ago
|
||
reassigning to mjudge
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
ok this is fixed. the fact that you cant select the " is OK thats a design
decision that is being looked at this week. bug 12460
It is probably best to allow everything to be selectable because
users have no idea that the " is generated content.
Notice that for users who don't want the ", they can still select the
appropriate text. Whereas users who want " included in their selection
will find it strange that they cannot select it.
In edit mode (bug 12460), it shouldn't be editable. Rather, users
should be *informed* that they ought to go back to their initial
CSS "content:" and edit it. I put the emphasis on *informed*, because
otherwise, it will be undiscoverable to an user who is not the initial
writer of the document.
|
Reporter | |
Comment 11•25 years ago
|
||
I don't think making " not selectable is satisfactory. Indeed, as
I have explained above, it is already possible to avoid it when
doing a selection. But those who want to select it are going to
wonder why they cannot select it. They will not know that it is
generated content, and what this means.
|
|
Reporter | |
Comment 12•25 years ago
|
||
Can somebody tell me the rationale of the decision that " should not be
selectable?
You need to log in
before you can comment on or make changes to this bug.
Description
•