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)
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.
I'm going to take a look at the paragraph selection issues for Mike.
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.
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]
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.)
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
it would be outstanding if Akkana could get this in for nsbeta2, but if not, then I will put this on the nsbeta3 radar
Long-term problems, at risk for nsbeta2.
just filed related 3x click prob: bug 40847
*** 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.
moving to nsbeta3 - low priority, removing nsbeta2 keywords
Per beppe, futuring this bug. (Though it may turn out to be trivial once 16311 is fixed.)
adding help wanted keyword
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from email@example.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...
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.
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
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
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.
it looks like people don't mind this being reopened.
Giving to nobody
*** 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.
> 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
------- 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
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.
Created attachment 192347 [details] [diff] [review] patch 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?
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.
Created attachment 192354 [details] [diff] [review] patch v1.1 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.
Created attachment 192355 [details] testcase breaking patch v1.1 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.
Created attachment 192372 [details] [diff] [review] patch v1.2 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.
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.
Created attachment 192609 [details] [diff] [review] patch v1.3 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?)
Created attachment 192681 [details] [diff] [review] patch v1.4 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.
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.
(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!
This caused crash bug 306049
12 years ago
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.
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 :-)
*** Bug 189132 has been marked as a duplicate of this bug. ***