#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 Changed 17 years ago by
comment:2 Changed 17 years ago by
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 17 years ago by
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 17 years ago by
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 17 years ago by
(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 17 years ago by
| Owner: | set to Alfonso Martínez de Lizarrondo |
|---|---|
| Status: | new → assigned |
comment:7 Changed 17 years ago by
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 17 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:9 Changed 17 years ago by
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.
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).