Open Bug 280098 Opened 15 years ago Updated 11 years ago
Horizontal Rule is not selectable in embedded editor (midas)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 If you insert a horizontal rule into an embedded editable area (Midas), you can not easily select the hr. The expected selection behaviour would be such as when you insert an image (IE calls this a "ControlRange") with resize handles on the rule. As a result it can be tricky to delete horizontal rules, and it is not possible to drag/move them. When building more capable editors such as htmlarea (htmlarea.com) I can not see a good way of allowing the styling (without going to HTML view) of horizontal rules. I am considering bastardizing images 1 px images stretched appropriatly to use in place of horizontal rules, which is a very nasty solution but the best I can think of. Reproducible: Always Steps to Reproduce: 1.http://www.mozilla.org/editor/midasdemo/ 2.Click View HTML source checkbox 3.Enter <hr/> 4.Uncheck the checkbox 5.have fun trying to select the new horizontal rule. Actual Results: The horizontal rule can not be selected. Expected Results: The horizontal rule should be selectable by (left) clicking it, producing resize handles and allowing drag-move in the document in the same way as images may be.
Some of this is a regression from bug 38370 (the fact that you can't select; the resize handles and such should be in a separate bug). Perhaps we should have a -moz-user-select value that makes GetContentAndOffsetsForPoint on nsFrame behave like it used to behave on HRuleFrame? I suspect that will solve the selection issue...
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug still exists in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 (Firefox 1.6 Beta 1)
This in the wrong component... roc, thoughts on comment 1? ccing Uri too, since he's been poking around in the selection code, I believe.
Assignee: mozeditor → selection
Component: Editor → Selection
QA Contact: bugzilla
Sounds reasonable to me
This also happens in wXP, OS: All And this problem also exists in Thunderbird, it isn't just Midas.
OS: Linux → All
So I tried doing this.... but even without any changes, clicking on the <hr> makes it possible for me to drag it or delete it. The only problems are that a selected <hr> does not paint said selection in any reasonable way and that the target area is kinda small...
You need to log in before you can comment on or make changes to this bug.