Open Bug 306240 Opened 19 years ago Updated 2 years ago

Triple-click (paragraph selection) also selects adjacent floats

Categories

(Core :: DOM: Selection, defect)

defect

Tracking

()

People

(Reporter: uriber, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: testcase)

Attachments

(4 files)

In the URL above, triple-click the lead (bolded) paragraph (starting with "Iraq's Sunni leaders..."). Notice that the image on the right, together with its caption, get selected in addition to the triple-clicked paragraph. A reduced testcase (and a patch) coming up.
Attached file testcase (deleted) —
Triple-clicking on the text in the middle also selects all four floats.
Attached patch patch (deleted) — Splinter Review
Stop on placeholder frames (replacing floats or absolutely-positioned elements) as well as on block frames and BRFrames.
Attachment #194099 - Flags: superreview?(roc)
Attachment #194099 - Flags: review?(roc)
Status: NEW → ASSIGNED
Keywords: testcase
I'm not 100% sure that our current behaviour is incorrect. With the new patch, a placeholder in the middle of a line will cause us to only select half the paragraph (from the user's point of view).
I thought about that, so I checked Safari, and it behaves like my proposed patch, i.e. the selection stops when reaching a mid-paragraph float. It would be interesting to see what other browsers do. I also think that including a mid-paragraph float in the selection would be unexpected from the point of the user - because the selected text would appear garbled, with the floated text appearing in the middle of the paragraph. The best solution might be to skip floats, and continue with the following/previous text. That requires non-contiguous selection, which I'm not sure we can do. In any event, I would consider that an enhancement, and for now go with the current patch.
(In reply to comment #4) > I also think that including a mid-paragraph float in the selection would be > unexpected from the point of the user - because the selected text would appear > garbled, with the floated text appearing in the middle of the paragraph. I'm not sure what you mean here.
Attached file mid-paragraph float (deleted) —
A testcase is worth a thousand words (especially if those words are mine). Triple-clicking the main sentence with the current implementation, copying, and pasting into a text editor, yields: The rain in Spain some random footnote about Spain falls mainly on the plain. This is actually not as bad as I thought, because line breaks are inserted before and after the float. But still, I think it might be confusing.
With Dunderklumpen's help on IRC, I verified that terminating the selection when reaching a float (as with the proposed patch) is also IE6's behavior (we used the second testcase above).
> The rain in Spain > some random footnote about Spain > falls mainly on the plain. Well, that is basically what the markup is. I could argue that this is what should be pasted. The question is, do we want to paste something as close as possible to the underlying content, or something that corresponds more visually with what's displayed?
(In reply to comment #8) > The question is, do we want to paste something as close as possible to the > underlying content, or something that corresponds more visually with what's > displayed? Although in theory the former might be morre corect, I think that in practice we have to go with the latter, because most existing HTML is written for the purpose of "looking right" rather than being semantically correct mark-up. Specifically, I think the in BBC site (linked from the URL field), the current behavior is not what the user would expect. Also, floats are often used as a means for creating column layouts, which could, again, cause unexpected bahavior (although I admit I haven't found an actual case. I'll post a testcase soon). It might be desirable to treat mid-paragraph floats differently from floats immediately preceding or following a paragraph. While the latter should, IMO, not be selecteded by triple-click, mid-paragraph floats can arguably either be selected as part of the paragraph, or skipped (creating an non-contiguous selection). However, I think this should be regarded as an enhancement (no browser that I know of currently supports it), and our first priority should be to implement the "standard" behavior.
Attached file column testcase (deleted) —
Based on http://glish.com/css/9.asp , although I had to tweak it a bit to actually get the wrong behavior. However, I'm pretty sure that there are real pages out there similar to this. Triple-click the first paragraph on the right-hand column (starting with "This page is part of"). Notice that the entire left-hand column is selected.
This is trunk-only, right? If it's OK with you, I'd like to leave things as they are. If we get complaints, I'll feel more inclined to do it your way. If we don't, I'd rather leave things as they are.
(In reply to comment #11) > This is trunk-only, right? If it's OK with you, I'd like to leave things as they > are. If we get complaints, I'll feel more inclined to do it your way. If we > don't, I'd rather leave things as they are. Yes, this is trunk only. And sure, we can leave it this way until we get complaints. But I'm pretty sure we'll get them, eventually.
Comment on attachment 194099 [details] [diff] [review] patch cancelling review for now
Attachment #194099 - Flags: superreview?(roc)
Attachment #194099 - Flags: superreview-
Attachment #194099 - Flags: review?(roc)
Attachment #194099 - Flags: review-
I'd like to add my opinion that it would be nice to fix this. I have triple click set to the old behavior of selecting a line instead of a paragraph. I've found pages at computerworld.com where triple clicking on a lead line will select that line plus the entire right sidebar. See http://www.computerworld.com/governmenttopics/government/legalissues/story/0,10801,108888,00.html and triple click on "The company rejected the allegations, telling the European Commission it has done no wrong" at the top of the article. Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060222 SeaMonkey/1.5a
QA Contact: selection
Blocks: 783783

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: uriber → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: