Closed Bug 32807 Opened 24 years ago Closed 19 years ago

Triple-clicking should select paragraph, not line

Categories

(Core :: DOM: Selection, enhancement, P3)

Product:
Core
Component:
DOM: Selection
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: mpt, Assigned: uriber)

References

Details

(Keywords: helpwanted)

Attachments

(1 file, 5 obsolete files)

patch v1.4
11.34 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review 
Build: 2000031908, MacOS 8.6

To reproduce:
* Go to any Web page which has a multi-line chunk of text.
* Triple-click in the middle of a line of text.

What would happen in a perfect world:
* The block (paragraph, DIV, list item, etc) gets selected.

What is probably supposed to happen at the moment:
* The current line (as determined by word wrapping with the current window size)
  gets selected.

What actually happens:
* The current line gets selected, except for the first character in the line.
Note: triple click should select the paragraph.  Setting to M16 for now.
Eli or someone--if you have a chance, could you confirm that Linux has the same 
selection behavior?  (I already know that triple click doesn't work on Windows)
Summary: Triple-clicking doesn't select a line → Triple-clicking doesn't select all of the line/paragraph
Target Milestone: M16
Matthew, could you possibly provide an example? It sounds like a duplicate of 
16311 from limited information available. Thanks!

It worked on every line I tried it on, which is why I didn't provide a testcase. 
Someone else is using the computer Mozilla is installed on right now, so I can't 
give you one ...

I don't think it's a dup of 16311. If I read bug 16311 correctly, selection 
starts/stops at a style change instead of the beginning of a line. In this bug, 
however, selection starts at the second character in a line instead of the first 
(or instead of the beginning of the paragraph, like brade says). So unless 
Mozilla is internally using some style hack to represent the first character of a 
line, this isn't a dup.

updating keyword and status whiteboard to reflect that this is a beta 2 feature 
work bug that the Composer team deems a must fix for beta 2.
Severity: normal → major
Keywords: beta2
Priority: P3 → P1
Whiteboard: Composer feature work
Keywords: nsbeta2
I'm going to take a look at the paragraph selection issues for Mike.
Assignee: mjudge → akkana
Keywords: beta2
In my linux build from today, triple-click in an html page (I'm using the
default page, http://www.mozilla.org/quality/checkin-guidelines.html) selects
all of the current line (including the first character).  Is it possible that
you were looking at a page that used a first-letter style?  (In which case this
bug would be a dup.)  Or is this perhaps Mac-specific?

As to line vs paragraph: in html by default, it should be selecting paragraphs,
but there was a bug in that code long ago and I think Mike may have switched the
default to line selection because it was less buggy.  I will investigate as part
of looking at bug 16311.
Akkana--could we keep this bug for the issue of tracking line vs paragraph 
selection for triple-click?  This one seems most appropriate to me of those I 
found in bugzilla.

Talked with Kathy, and we agreed to use this bug to track line/paragraph issues.

Paragraph selection is disabled now, but if you turn it on, it has all the same
problems it used to have, of extending through the text node up to the next
non-text node.  I'll be looking at this, and when it works better, will enable
it when appropriate.
Status: NEW → ASSIGNED
CC:ing akay & masri in case they might have any helpful comments Re: akkana's 
question. I think one of them wrote a bug about how the Mac should behave a while 
ago.

Eli, I think this is the part where brade & akkana shoot you for cc'ing me. :)

If this bug covers text selection issues, then the following URL might be of some 
use.

http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-217.html

These are expected selection behaviors, at least on Mac. I'm sure other platforms 
have similar selection guidelines.

You'll notice that they really only discuss the double-click gesture here. That's 
the only one mandated. The others are "bonus" gestures, designed to make the 
user's life easier. A good example is AppleWorks: tripple-click selects a line of 
text, and 4 clicks (a quad-click?) selects an entire paragraph. You can think of 
it as extending the expected behavior.

- Adam

This bug is only for paragraph select/triple-click issues.
16352 is the bug for double-click/word select issues.
Thanks for the url, though; I'll take a look at it when I get the infrastructure
to the point where the details of word breaks actually matter.

Unix, incidentally, uses triple-click to select line, quadruple-click to select
everything (whole document).  I use quad-click surprisingly often (usually to
remove autoquoted mail text).
I don't know of any Mac programs (off the top of my head) that allow you to 

select whole paragraphs via any amount of clicking. The Mac almost exclusively 

uses triple-clicking to select a line, rather than a paragraph. Until now, I 

didn't even know there were paragraph select/triple-click features being used in 

Mac OS.



I must be missing something - you really lost me when "paragraph selection" was 

introduced into this bug.


The difference between an HTML editor and any legacy (Mac, Windows, or whatever) 
app that allows selection of a line, is that HTML really has no concept of a 
`line'. Because window widths, font choices, and other factors vary much more in 
renderings of a single HTML document than they do with a word processing 
document, talking about `lines' is pretty meaningless (except for styling, e.g. 
CSS's first-line selector).

While authors continue not to use the ABBR element where they should, we can't 
tell where sentences begin and end either (we can't tell whether ". " is the end 
of a sentence or just the end of an abbreviation). Otherwise we'd be able to use 
triple-click to select a sentence, which would be cool.

So I think the most useful assignment of a triple-click is to select the 
`paragraph'; or more precisely, to select the innermost current block-level 
element -- whether that be a paragraph (P), or a division (DIV), or an address 
(ADDRESS), or table cell (TD, TH), or whatever. (The content between the start/
end of a block level element and a BR element could also count as a dummy block-
level element, I guess.)

Selecting a sentence would be cool!  But Matthew's right, it probably wouldn't
work in practice because of abbreviations and ellipses and dotcoms and such.

Yesterday I tried to implement just what Matthew describes -- climb up the frame
tree to the nearest block frame, get the corresponding node, and select
everything inside that node.  It was a failure: what I learned was that users
won't want to select html block elements; they want to select things that *look*
like paragraphs.  For instance, in the default url for mozilla builds,
triple-clicking in the first thing that looks like a paragraph selects the whole
document, because that text is not enclosed inside a <p>, <div> or other block
frame.

Currently I'm thinking that I'll have to search forward and backward in the
frame list for the nearest "frames that look to the user like paragraph
delimiters" (whatever that means -- I'd probably have to maintain a list of
qualifying tags or frame types) before and after the clicked point.  Ugh. 
Anyone have any better ideas?
Didn't even pay attention that this was Composer/HTML. Makes sense now. Thx.


[nsbeta2+ until 5/16]
Whiteboard: Composer feature work → [nsbeta2+ until 5/16] Composer feature work
By `the first thing that looks like a paragraph' in `the default url for mozilla 
builds' I assume you mean the first news item in <http://mozilla.org/>, in which 
case:
* why aren't you interpolating the existence of a </p> tag at the end of the
  paragraph, even though it's not in the markup?
* why isn't TD in your list of block elements?
* did you do what I suggested, and treat BR as a pseudo-paragraph-divider?

At least on the day when I was testing this, there was no <p> tag at the
beginning of the first real content on that page.  Had there been one, the
algorithm would have worked.  

It probably did see <td>, and really only selected the contents of the td (i.e.
the whole content page), not the mozilla "sidebar".  I don't remember, would
have to check.  But this is clearly not what a user would expect.

Clearly I'll have to look for <br> and similar tags.  But that's a completely
different algorithm involving moving up and down in nsILineFrames, and I haven't
figured out how to do it yet.  I can't just climb up the document tree or the
frame tree to find a block node, because that won't tell me where the br and
other similar tags are.
Changing summary to clarify that this bug now covers only paragraph selection. 
16311 is the bug for line selection.  (They look like the same problem, but it's
actually different code with somewhat different, though related, fixes.)
Summary: Triple-clicking doesn't select all of the line/paragraph → Triple-clicking doesn't select all of the paragraph
this is not really a 'new' feature, this is really a bug and should be noted as 
such, removing commnet in whiteboard stating this is feature work
Whiteboard: [nsbeta2+ until 5/16] Composer feature work → [nsbeta2+ until 5/16]
it would be outstanding if Akkana could get this in for nsbeta2, but if not, 
then I will put this on the nsbeta3 radar
updating whiteboard
Whiteboard: [nsbeta2+ until 5/16] → [nsbeta2+]IN nsbeta2
Long-term problems, at risk for nsbeta2.
Priority: P1 → P3
just filed related 3x click prob: bug 40847
OS: Mac System 8.5 → All
Hardware: Macintosh → All
*** Bug 40847 has been marked as a duplicate of this bug. ***
I have the code mostly written for paragraph selection, but line frames don't
work right and are too easily blocked by style changes (bug 16311) and everyone
including me keeps getting confused about the relationship between these two
bugs.  Marking a dependency to reduce the confusion.
Depends on: 16311
moving to nsbeta3 - low priority, removing nsbeta2 keywords
Keywords: nsbeta2 → nsbeta3
Whiteboard: [nsbeta2+]IN nsbeta2
Target Milestone: M16 → M18
Per beppe, futuring this bug.  (Though it may turn out to be trivial once 16311
is fixed.)
Keywords: nsbeta3
Target Milestone: M18 → Future
adding help wanted keyword
Keywords: helpwanted
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
So this won't be fixed for RTM? Broken for me on Windows 2000, Oct 19 build. 
Bummer.
Right, this won't be fixed for RTM.  The line selection code is just too horked,
and none of us who have tried to make it work right have gotten anywhere with
it.  Sorry.
Anthony is taking over selection bugs.
Assignee: akkana → anthonyd
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Thinking about this some more, triple-clicking should select the innermost 
element around the cursor position which has its `visibility' property set to 
anything except `hidden' and its `display' property set to any of `block',
`list-item', or `table-*'. That way, we'll do the Right Thing no matter whether 
the document is HTML or XML.

this needs to go back on the block for reconsideration of what the correct 
behaviour is, what the expected behaviour is, and what we are willing to do 
about it.  setting to 0.9 to put on my radar.

anthonyd
Target Milestone: Future → mozilla0.9
triple clicking is not standard on all applications on al platforms (ie. it 
behaves differently on different applications on each single platform).  Right 
now we triple click and select to the line break.  this is the way its gonna 
stay, at least for the forseeable future.

anthonyd
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
I don't get it. Why is triple-clicking doing different things in different 
applications a valid excuse for triple-clicking doing something in Mozilla which 
is practically useless?

If this is too hard for you to implement, then reassign to nobody and future it.

reopen this bug; it is *not* an invalid bug/feature request.
Target Milestone: mozilla0.9 → Future
it looks like people don't mind this being reopened.
Severity: major → enhancement
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Giving to nobody
Assignee: anthonyd → nobody
Status: REOPENED → NEW
*** Bug 75922 has been marked as a duplicate of this bug. ***
Just for the record, IE on Windows selects paragraphs when you triple-click (or
at least tries...  doesn't work in plaintext documents very well).  Also, it
does not clear the select on the fourth click.  This is beneficial for those of
us who have mouse buttons that perform a double-click so you can just
middle-click twice to select a paragraph.
Blocks: 97053
No longer blocks: 97053
> triple clicking is not standard on all applications on al platforms

Double and triple click are fairly standard (in advanced software), from what
I've seen in UNIX and windows apps.

Double click selects the word under the pointer. Draging after a double click
selects by the word. Mozilla currently reverts back to per-character selection
during a drag. That's definatly bug material.

Triple click selects the logical group under the pointer. For something like a
text editor, or a terminal emulator, that's the current line. HTML, however, has
no concept of lines. Text flows, and wraps. Content is in sections; div's, p's,
li's, and so forth. This is the same way Word processors work. MS Word gets it
right... triple click selects the section, whether it's a heading, a paragraph,
or a list item. And, like double click, draging after a triple click needs to
select per-section. It's alot easier to select three paragraphs of text by
triple-clicking and draging from the anywhere in middle of the first to anywhere
in the middle of the third, then it is to try and line up perfectly with the
first and last characters (and if you're out of the edge characters bounding box
by 1 pixel, and there's tables around, you typically highlight the whole page
and copy/print it without realizing...VERY annoying).
double-click drag selection (word selection) is covered in bug #16203; that is a 
separate issue

-->selection module owner
Assignee: nobody → mjudge
QA Contact: blakeross → tpreston
------- Additional Comment #11 From Akkana 2000-05-02 15:38 -------
> Unix, incidentally, uses triple-click to select line, quadruple-click to select
> everything (whole document).  I use quad-click surprisingly often (usually to
> remove autoquoted mail text).

Like you, I do this all the time, or did with netscape, and for the same reason
- to remove autoquoted mail text.

This bugs seems to be relating to html a lot, but it doesn't work in the email
compose window either. That, to me, is way more important, and I don't see
anyone mentioning it here.

If noone's going to do anything with this for the browser, perhaps we could move
it to the email client.

Does this need a different bug?

Max.


Additionally, functionality like the old MS-DOS "Works 3.0" would be spectacular.  It allowed strangeness like clicking on the left-hand margin to select lines, or doing odd left+right clicks to select a sentance.  I can elaborate if there is some interest in this.
Currently, triple-clicking seems to select the current line as defined by the
present word-wrapping situation. This is counterintuitive, as the Web is based
on structured information, not on the final rendered form of a page. People
expect to be able to select information based on its logical grouping, not on
how it happens to have been word-wrapped by the browser.

At our campus, we've switched 6 systems over to Mozilla for a trial period. Now
that the students are familiar with Mozilla's slightly different feel, one of
the primary complaints is text selection behaviour, and in particular the
failure of triple-click to select a logical paragraph.

These are people in the the real world (mostly English or languages majors), who
need to work with large amounts of textual information on a daily basis.

I'd appreciate it if triple-click could be fixed to select a paragraph. This is
also the default behaviour in Microsoft's Internet Exporer (which our other
workstations use) and Word, which are very popular in the academic world, so it
would also help make the Mozilla environment more familiar to these users. 

I noticed that a previous post claims this bug is minor, but it's one that
bothers a lot of users in the real world, and a fix would be much appreciated.
Thanks!
I find the arguments on current line selection behaviour being
"counterintuitive" to be rather specious. UI gestures should be as similar as
possible from one type of application to another. A normal Web surfer has no
clue about the HTML used to markup a page; breaking selection in this way would
likely appear broken to a normal user, who would wonder why Mozilla's selection
doesn't work the way their word processor does.

And let's talk about a word processor for a second. Let's say you type a
paragraph in 12 pt font. You then select the paragraph, change the point size to
18 point. Then you do a tripple click, or whatever gesture that word processor
accepts to select a full line of text. The selection goes to the end of the
line, not the end of a sentence. And this new selection will be different from
the previous one. Broken? I don't think so. I think thru consistency, the user
is trained that this behaviour selects the full line of text, whether their
sentence, section, or whatever word you choose to use ends or not.

Normally, I find Apple's UI to be the most consistent, but there is no
consistency in click behaviour beyond the double-click. In Apple's Jaguar UI
guidelines document,

http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AquaHIGuidelines.pdf

pp. 165, they say, "Some applications support triple-clicking. For example, in a
word processor, the first click sets the insertion point, the second click
selects the whole word, and the third click selects the whole sentence or
paragraph. Supporting more than three clicks is inadvisable."

Here's what happens when you tripple click in various applications in MacOS X
10.2 (Jaguar):

TextEdit: paragraph selection. Moving the mouse anywhere within the next or
previous paragraph selects that paragraph; you don't need to mouse accurately to
continue the same selection.

BBEdit (programmer's texteditor): line selection. Mousing anywhere within the
next or previous line selects that entire line.

AppleWorks 6: line selection. Mousing anywhere within the next or previous line
selects that line.

Quad-click (4 clicks) selects paragraph; mousing anywhere over next or previous
paragraph selects entire paragraph.

Do any other platforms have an actual standard for these behaviours? I'd be all
for following SOMEBODY's standard on this, if there is one. But without pointing
to specific UI guidelines, all arguments in this bug are nothing more than
personal preference.

- Adam
In response to comment 48 there are no real standards for triple clicking
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch05b.asp
This guide does not cover other mouse behaviors such as chording (pressing
multiple mouse buttons simultaneously) and multiple-clicking (triple- or
quadruple-clicking). Because these behaviors require more user skill, they are
not generally recommended for basic operations. However, you can consider them
for special shortcut operations

Near as I can tell IBM, KDE, and Gnome do not have any standards for triple
click either. OpenOffice triple click does the same as in Mozilla currently,
select the whole line, though there is a bug to make it select the whole sentence.
 
I think the more pressing issues with triple-click behavior are the bugs in the
current "select the line" implementation:
  bug 151700 - selecting all sorts of extra text that shouldn't be, especially
               notable on product titles at Amazon
  bug 175658 - selecting text different from what was actually clicked on
Summary: Triple-clicking doesn't select all of the paragraph → Triple-clicking should select paragraph, not line
Removing dependency on bug 16311. I don't think paragraph selection should
depend on line selection working perfectly, and I don't think the confusion
mentioned in comment 26 exists anymore.
No longer depends on: 16311
Attached patch patch (obsolete) — — Splinter Review 
The algorithm: search the frame tree upwards and backwards/forwards, starting
from the triple-clicked frame, until we either:
- find a "stop frame" (a block frame or a BRFrame)
- reach beyond an ancestor block frame

I modelled this behaviour after Safari's. I think it makes sense.

This patch will obviously require intensive reviewing.
Some questions:
- Is QIing for nsILineIterator really the best/only way to test for a block
frame?
- How should the preference issue be handled?
Assignee: mjudge → uriber
Status: NEW → ASSIGNED
Attachment #192347 - Flags: review?(roc)
Target Milestone: Future → mozilla1.9alpha
Comment on attachment 192347 [details] [diff] [review]
patch

Sorry, this wasn't ready for review yet. I'll do some more testing and
bug-fixing and post an updated patch.
Attachment #192347 - Flags: review?(roc)
Attached patch patch v1.1 (obsolete) — — Splinter Review 
I was sometimes using the frame tree in the final stage, where I should have
been using the content tree. Fixed that.

I went through all the layout tests, and there is still one case which is
broken. However, it seems to not be my fault (although it probably is). I'll
post a small testcase with explanations soon.
Attachment #192347 - Attachment is obsolete: true
Attached file testcase breaking patch v1.1 (obsolete) — 
With patch v1.1, you can not paragraph-select the first line in this testcase.
(This is invalid HTML - but that's no excuse, of course).

The reason is that for the nsBlockFrame (following the nsInlineFrame), when I
ask for GetContent(), I get the nsHTMLSpanElement, instead of the expected
nsHTMLDivElement!

I can't understand why this happens. Could this be a bug in assigning content
elements to frames? Or is it intentional, meaning that I will have to somehow
work around it?
Comment on attachment 192354 [details] [diff] [review]
patch v1.1

Last spam for today (I hope):
I discovered that attachment 192355 [details] is also broken with the current
(line-selection) behaviour. This makes me more confident that it's not my fault
- so now asking for a review.
Attachment #192354 - Flags: review?(roc)
Attached patch patch v1.2 (obsolete) — — Splinter Review 
Oh, it was a "special" frame (some frames think they're so special!)

Anyway, fixed it by allowing us to "fall through" special block frames when
searching for block frames and BRs. We are guaranteed to reach the "real" block
frame immediately, since special block frames always have block frames as their
first and last children.
Attachment #192354 - Attachment is obsolete: true
Attachment #192372 - Flags: review?(roc)
Attachment #192354 - Flags: review?(roc)
Why are you changing the preference? I think you don't need to.

You can QI for nsBlockFrame directly.

"special" frames are a whole little world of evil for dealing with the "block in
inline" problem (aka "IB"), which is what happens when a CSS block-level element
occurs inside a CSS inline element. Basically we split the inline into three frames:
-- an inline frame containing the element's children before its first block child
-- a block frame containing the element's children from its first block child to
its last block child
-- an inline frame containing the element's children after its last block child
These frames are all marked with the "special" bit. Frames containing no
children would not actually be created. Of course, line breaking of the first or
last inline frame would create extra inline frames in this list.

This looks like good 1.9 stuff.
(In reply to comment #58)
> Why are you changing the preference? I think you don't need to.

If I don't change it, then I need to set it to "true" by default. Currently it
doesn't exist by default, and therefore considered "false". I'll do whatever you
prefer (that was actually my first question in comment #52).

> You can QI for nsBlockFrame directly.

OK, thanks. Will this cover also table cells, etc (e.g. anything that's not
inline)? I guess I'll just check this myself, as soon as I'm back at my
development machine.

> "special" frames ...

I kind of figured out this stuff myself (and factored it to the v1.2 patch).
Sorry I didn't make it clear, and thanks anyway for the explanation.

> This looks like good 1.9 stuff.

Yay!
(In reply to comment #59)
> (In reply to comment #58)
> > Why are you changing the preference? I think you don't need to.
> 
> If I don't change it, then I need to set it to "true" by default. Currently it
> doesn't exist by default, and therefore considered "false". I'll do whatever
> you prefer (that was actually my first question in comment #52).

All preferences should have a default value in all.js. You can put a default
value there of "true".

> > You can QI for nsBlockFrame directly.
> 
> OK, thanks. Will this cover also table cells, etc (e.g. anything that's not
> inline)? I guess I'll just check this myself, as soon as I'm back at my
> development machine.

Table cell frames contain an anonymous block child, so you should be OK. Test
it, of course.
Comment on attachment 192372 [details] [diff] [review]
patch v1.2

OK, thanks again. I'll be back in a couple of days with a revised patch.
Attachment #192372 - Flags: review?(roc)
Attached patch patch v1.3 (obsolete) — — Splinter Review 
Changes from 1.2:
- Back to using browser.triple_click_selects_paragraph, but now initialize it
to "true" in all.js
- QI directly on nsBlockFrame, instead of nsILineIterator (this was not as
straightforward as I thought, but biesi helped me on #developers). Tested this
and it seems to work well, including with tables.
- Vanity. (I'm allowed to do that, right?)
Attachment #192355 - Attachment is obsolete: true
Attachment #192372 - Attachment is obsolete: true
Attached patch patch v1.4 — — Splinter Review 
Now with some (lame) handeling of preformatted text.
As the comment says, what we really want is to treat newlines in preformatted
text just as if they were BRFrames. However, that turns out to be Very Hard (at
least for me).

The current solution - forcing line-selection when the clicked frame is
preformatted - works for cases where the preformatting is declared on a block
element, which I think should account for about 99% of real-world situations.
Attachment #192609 - Attachment is obsolete: true
Attachment #192681 - Flags: review?(roc)
Comment on attachment 192681 [details] [diff] [review]
patch v1.4

(In reply to comment #63)
> As the comment says, what we really want is to treat newlines in preformatted
> text just as if they were BRFrames. However, that turns out to be Very Hard
> (at least for me).

Why's that? But this is OK.

This looks pretty good. This is a good time to step back and clean up
PeekOffset, which will help us fix up a lot of stuff ... but no reason not to
take this code now.
Attachment #192681 - Flags: superreview+
Attachment #192681 - Flags: review?(roc)
Attachment #192681 - Flags: review+
(In reply to comment #64)
> Why's that?

Two reasons:
1. Because the way I'm doing it has an underlying assumption that a paragraph
boundary is at a content boundary. FindBlockFrameOrBR() returns a frame, and
PeekOffsetParagraph() then just does a GetContent() on that frame and stops
after/before that content. This won't work when the boundary is in the middle of
a text content element.
2. Because I'm not even sure how to detect this situation (do I have to look at
the actual text of the frame and see if there's a line break there? Yuck!)

So my feeling is that even if manage to do this, it will make the code much more
complicated, and it's really only needed for a situation which I think is almost
theoretical (inline pre-formatted elements). I  might get back to it later, but
I don't want it to hold up the patch.

Assuming this is still OK with you, could you please check in for me (on the
trunk) this patch, as well as my patch for bug 16311? Let me know if you want me
to do the "obtaining a checkin window" part, but I think it makes more sense for
you to do it so that it fits your schedule.
Also, if/when you check this in, please fix my typo in the comment ("boundray"
=> "boundary"). Sorry about that.
(In reply to comment #65)
> 1. Because the way I'm doing it has an underlying assumption that a paragraph
> boundary is at a content boundary. FindBlockFrameOrBR() returns a frame, and
> PeekOffsetParagraph() then just does a GetContent() on that frame and stops
> after/before that content. This won't work when the boundary is in the middle
> of a text content element.
> 2. Because I'm not even sure how to detect this situation (do I have to look
> at the actual text of the frame and see if there's a line break there? Yuck!)

Text frames don't span lines, remember, so a text frame with a hard line break
will always be the last text frame on the line (and the line break character
will be at the end).

> So my feeling is that even if manage to do this, it will make the code much
> more complicated, and it's really only needed for a situation which I think is
> almost theoretical (inline pre-formatted elements). I  might get back to it
> later, but I don't want it to hold up the patch.

Sure. Let's keep it in mind when we fix PeekOffset.

> Assuming this is still OK with you, could you please check in for me (on the
> trunk) this patch, as well as my patch for bug 16311? Let me know if you want
> me to do the "obtaining a checkin window" part, but I think it makes more
> sense for you to do it so that it fits your schedule.

Sure, I'll land it.
checked in. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 19 years ago
Resolution: --- → FIXED
This caused crash bug 306049
Depends on: 306049
I filed bug 306895 on two cases where this patch is wrong, imo: preformatted
text and textareas.  In both cases, I think the line is the logical unit
triple-click should select.
Is there a chance this can get approval1.8.1?

If so, I'll make a 1.8 branch patch combining the fixes to the regressions and follow-ups, and formally ask for approval.
Depends on: 306895
Flags: blocking1.8.1?
To be honest, I don't think it's worth putting this in 1.8.x.
(In reply to comment #72)
> To be honest, I don't think it's worth putting this in 1.8.x.

OK, thanks for saving me the time of making that combined patch :-)
Flags: blocking1.8.1?
Depends on: 326932
*** Bug 189132 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: