Open Bug 634816 Opened 13 years ago Updated 3 years ago

Images in Table - Handle Issue

Categories

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

5 Branch
x86
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: stadster, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13
Build Identifier: 2.0.11

If you insert images and text inside a table, the handles will appear in incorrect location when you select an image.  This appears to not only be a problem with Seamonkey, but with the FF browser as well.  The same error occurs when I tested other web-based editors in Firefox.

Reproducible: Always

Steps to Reproduce:
1.Insert a Table
2.Insert an image and some text, in next paragragh insert an image and text again
3.Select an image; this works fine.
4.Click in the text, now click back on the image.  Note: you are unable to select it on the first click - the handles will actually appear elsewhere on the page.  You must click on it again to get the handles correctly positioned on the image.

Actual Results:  
As noted, image handles do not work correctly inside tables.  This also occurs in Firefox when using other web-based html editors such as CKEditor.  This error does not occur in IE or Chrome.

Expected Results:  
Expectation:  when you select an image inside a table, the handles appear on the image.  If you click on text, I believe there should be no handles.
Version: unspecified → SeaMonkey 2.0 Branch
Is this DUP of Bug 575752 - ContentEditable: Image/Table resize handles are misplaced?
(In reply to comment #1)
> Is this DUP of Bug 575752 - ContentEditable: Image/Table resize handles are
> misplaced?

Yes, somewhat.  #575752 uses the CKEditor as an example of when this bug occurs.  I have done further testing and found the same error reproducible in Seamonkey.  Thus, I believe the bug is in Firefox, not the html editors.

I am surprised this bug has not been addressed, as it really makes using an html editor (even Seamonkey) quite difficult, and ugly, to use.

I do not know how Bugzilla works.  I would even be willing to offer a reasonable reward if it would get this issue resolved.  It is a real pain.
Component: Composer → Editor
Product: SeaMonkey → Core
QA Contact: composer → editor
Version: SeaMonkey 2.0 Branch → 5 Branch
I've tried to reproduce against current comm-aurora/mozilla-aurora and cannot. Could you test against Firefox 7 or SM2.4?

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.