280098 - Horizontal Rule is not selectable in embedded editor (midas)

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[James Sleeman]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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...

Comment 2

[Gervase Markham [:gerv]]

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/

Comment 3

[nikotto]

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)

Comment 4

[Kathleen :Brade]

confirm based on comment 1 and comment 3

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sounds reasonable to me

Comment 7

[Alfonso Martinez]

This also happens in wXP, OS: All

And this problem also exists in Thunderbird, it isn't just Midas.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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...

Comment 9

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.