Ticket #1285 (closed Bug: fixed)

Opened 7 years ago

Last modified 7 years ago

Opera: context menu hack causes empty P tags

Reported by: hallvord@… Owned by: alfonsoml
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

comment:1 in reply to: ↑ description Changed 7 years ago by fredck

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 7 years ago by fredck

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 7 years ago by fredck

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 follow-up: ↓ 9 Changed 7 years ago by hallvord@…

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 7 years ago by hallvord@…

(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 7 years ago by alfonsoml

  • Status changed from new to assigned
  • Owner set to alfonsoml

comment:7 Changed 7 years ago by alfonsoml

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 7 years ago by alfonsoml

  • Status changed from assigned to closed
  • Resolution set to fixed

comment:9 in reply to: ↑ 4 Changed 7 years ago by fredck

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 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy