Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#1285 closed Bug (fixed)

Opera: context menu hack causes empty P tags

Reported by: Hallvord R. M. Steen (Opera Software) Owned by: Alfonso Martínez de Lizarrondo
Priority: Normal Milestone: Opera Compatibility
Component: UI : Context Menu Version: SVN (FCKeditor) - Retired
Keywords: Cc:

Description

Due to the contextmenu hack for Opera, right-clicking in the document inserts an INPUT tag in the DOM. Since Opera now tries to keep block-level formatting consistent, it will surround the unexpected INPUT tag with P tags. When done processing the right-click, the script will remove the INPUT and an empty P element will be left behind. Thus more and more empty P tags occur at the end of the document during editing.

Change History (9)

comment:1 in reply to:  description Changed 10 years ago by Frederico Caldeira Knabben

Since Opera now tries to keep block-level formatting consistent

This is quite a dangerous thing. Useful in some cases, but could become a big problem on applications that try to have a better control of the DOM, like FCKeditor.

My main concern here is that we have a powerful feature at FCKeditor, called "Enter Handler". We can configure FCKeditor to produce <p>, <div> or <br>. So, depending on this setting, our default block element change. We could have a <p> for it, but also a <div>. The third case is the most delicate. We don't have blocks here at all, only text and <br>s. Blocks may appear only if formatting the text for headings, lists, etc... I know this is not a standards dream, but that's a feature widely used by our users (mainly by those how didn't really care with standards).

comment:2 Changed 10 years ago by Frederico Caldeira Knabben

We are appending our <input> inside (doc.body||doc.documentElement) (I think we can safely use doc.body only here anyway). So, Opera's fix would be adding a <p> for our <input>, and nothing else would be available for that <p>, right? So it is safe to assume that the <p> can be removed, together with the <input> by our context menu hack, right?

comment:3 Changed 10 years ago by Frederico Caldeira Knabben

Here again... I enforce my note... Browser's doing "fixes" automatically are a really bad thing. If I don things in the DOM, I expect them to be the way I wanted it. We already have enough problems with IE in this sense... please don't give Opera the same destiny!

comment:4 Changed 10 years ago by Hallvord R. M. Steen (Opera Software)

Hm.. Being more consistent with P tags instead of just BR on enter has been widely requested by other RTE developers. :( (and it makes our life a lot more complicated to try to do so..)

Anyway, I think the simple workaround here is to check if the invisible input has a P parent whose childNodes.length==1, and if so remove it. If you do this when you remove the input again it should be fairly simple and safe to resolve this issue.

comment:5 Changed 10 years ago by Hallvord R. M. Steen (Opera Software)

(and the enter handler stuff already works because Opera does the right thing when you prevent the default action of the enter key. what we see here is the block-logic kicking in on other DOM modifications which may of course cause unexpected problems :( Perhaps the WHATWG or Web-API standardisation groups could help us standardise a way to switch the editor from "block validating" to "raw" mode, or something?)

comment:6 Changed 10 years ago by Alfonso Martínez de Lizarrondo

Owner: set to Alfonso Martínez de Lizarrondo
Status: newassigned

comment:7 Changed 10 years ago by Alfonso Martínez de Lizarrondo

Fixed with [878]

I've added a P manually so if the behavior of Opera changes our code won't be affected.

comment:8 Changed 10 years ago by Alfonso Martínez de Lizarrondo

Resolution: fixed
Status: assignedclosed

comment:9 in reply to:  4 Changed 10 years ago by Frederico Caldeira Knabben

Replying to hallvord@opera.com:

Hm.. Being more consistent with P tags instead of just BR on enter has been widely requested by other RTE developers. :( (and it makes our life a lot more complicated to try to do so..)

Those lazy guys :)

But... it just sounds bad for me to have <body><p><input></p></body>, if I say body.appendChild(input). I feel it quite buggy.

In the other hand, producing <p> tags on enter is ok... we have a custom implementation for it in any case.

There are some cases where things get hard for us. We are facing it right now with IE. If you do CTRL+A and then DELETE, you have a <p></p> automatically appended to the <body>. I wanted a <div> there instead if EnterMode=div. Having an empty <body> would be even better.

We are walking in a situation where the browser will be used for caret positioning only. All the rest will be handled with custom operations... that seams the only way to go, so please consider this at Opera, to avoid breaking things at our side when proposing DOM automations.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy