Opened 8 years ago
Closed 8 years ago
#4058 closed Bug (fixed)
[FF3,5] Sometimes WYSYWIG area is not editable
| Reported by: | arczi | Owned by: | garry.yao |
|---|---|---|---|
| Priority: | Normal | Milestone: | CKEditor 3.0 |
| Component: | General | Version: | |
| Keywords: | Firefox Confirmed Review+ | Cc: |
Description
Sometimes WYSYWIG area is not editable. Please try the attached test case.
The core is loaded from my server (nightly build).
Test: occurs in about 60% of cases, Firefox 3.5, reloading with F5, disabled cache.
Works fine in other browsers.
Attachments (3)
Change History (15)
Changed 8 years ago by arczi
comment:1 Changed 8 years ago by tobiasz.cudnik
It's possible that this can be fixed using this patch from #3905.
comment:2 Changed 8 years ago by arczi
Actual editor content:
<body><p>This is some <strong>sample text</strong>. You are using <a href="http://www.fckeditor.net/" _cke_saved_href="http://www.fckeditor.net/">CKEditor</a>.</p><script id="cke_actscrpt" type="text/javascript">window.onload = function(){var s = document.getElementById( "cke_actscrpt" );s.parentNode.removeChild( s );window.parent.CKEDITOR._["contentDomReadyeditor2"]( window );}</script></body>
Expected:
<body spellcheck="false"><p>This is some <strong>sample text</strong>. You are using <a href="http://www.fckeditor.net/" _cke_saved_href="http://www.fckeditor.net/">CKEditor</a>.</p></body>
This bug is very strange. Nothing has changed but now I can't reproduce it.
comment:3 Changed 8 years ago by garry.yao
- Resolution set to invalid
- Status changed from new to closed
I'm also unable to reproduce it.
comment:4 Changed 8 years ago by arczi
- Resolution invalid deleted
- Status changed from closed to reopened
There are two ways to reproduce:
-with ckeditor.js: disable NET panel in Firebug and minimize it.
-with ckeditor_source.js: disable the Firebug
I've made a simple patch to fix this bug. It is not optimal but hasn't big impact on the code what is good at this moment.
Changed 8 years ago by arczi
comment:5 Changed 8 years ago by arczi
- Keywords Review? added
comment:6 Changed 8 years ago by garry.yao
- Keywords Pending added
Still not able to reproduce it, attracting others to reproduce, though the double checking approach is desirable.
comment:7 Changed 8 years ago by fredck
- Keywords Confirmed added; Pending removed
I'm not able to constantly reproduce this issue, but it occasionally happens. We should try Artur's proposal, and only the time will tell us if it has been really fixed.
comment:8 Changed 8 years ago by fredck
- Keywords Review- added; Review? removed
I'm not able to reproduce it with proposed steps, but anyway, as I've said previously this is quite a rare and random issue. But the code looks good.
There are a few simplifications we could do though:
iframe.on( 'load', function( ev )
{
ev.removeListener();
!blockReady && contentDomReady( iframe.$.contentWindow );
});
As you can see, ev.removeListener() is equivalent to the call you're proposing at line 269. It removed the executing function from the current event.
Also, generally speaking, for code reduction, you can use 0/1 instead of false/true for internal flags like "blockReady", and you don't need to "initialize" it with false (or 0) because it will evaluate to false by default.
comment:9 Changed 8 years ago by fredck
- Owner set to arczi
- Status changed from reopened to new
Changed 8 years ago by garry.yao
comment:10 Changed 8 years ago by garry.yao
- Keywords Review? added; Review- removed
- Owner changed from arczi to garry.yao
- Status changed from new to assigned
I'm taking over the ticket to make sure we meet the deadline.
comment:11 Changed 8 years ago by fredck
- Keywords Review+ added; Review? removed
When committing:
- Please remove the "else" statement at line 330. It's superfluous.
- Please remove the [FF3.5] thing from the changelog. It's a general FF issue. I've seen this thing in FF2 and FF3 also.
comment:12 Changed 8 years ago by garry.yao
- Resolution set to fixed
- Status changed from assigned to closed
copy to trunk/