Custom Query
Results (25 - 27 of 11754)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#17010 | fixed | [API] Range#shrink method should allow for skipping bogus BR elements | ||
Description |
Make a selection as follows on a browser that puts bogus BR (e.g. Firefox): <table> <tr> [<td>Cell 1.1</td>] </tr> </table>
Try to call It should be possible to ignore such markup. |
|||
#17004 | wontfix | Post Editor - Useragent sniffing breaks it in Pale Moon | ||
Description |
I was directed to report this here by Rhett Buck at Invision Power Services (no, I'm not happy about being passed off when you're not the guys I'm paying for support). There is an issue with the CKEditor supplied to them, and on your own homepage as well. I am using the Pale Moon web browser, originally a fork from Firefox, but diverging into its own entity more recently. When attempting to use any function of IPB where the editor is needed, all that happens is the text box stalls with "Loading..." and never comes up. I have confirmed this across at least 5 sites now using IPB 4 where I have accounts and can post. There is also confirmation in other packages such as Drupal that the editor will do the same thing there. I have also verified that your own samples on the front page at ckeditor.com cause the red throbber to spin forever and nothing loads. I have traced this down to a useragent issue. Pale Moon defaults to this useragent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:3.2) Goanna/20170422 PaleMoon/27.3.0 If I change it to this: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 PaleMoon/27.3.0 then everything works properly, including the demos on your front homepage. Rhett then found another post on the Pale Moon forums where a user tracked it down even further to your ckeditor.js parsing the useragent incorrectly based on the rv: parameter. The link to that post is here: https://forum.palemoon.org/viewtopic.php?t=13035 Since Pale Moon is a legitimate desktop web browser used by millions of people, I think this is an issue that should be addressed in your detection scheme so that it benefits anyone using your package downstream, like IPB and Drupal, and users on sites with that software don't have to spoof a useragent to get access to something that clearly works just fine. This seems like a relatively simple fix that will maintain the intent of your compatibility check without locking out those of us who are by choice using something that's not Firefox, IE, or Chrome. |
|||
#17003 | fixed | Chrome Version 58.0.3029.81 Crashes WIth Form Inputs | ||
Description |
Steps to reproduce
Firefox (53.0) seems to not have this issue and works normally. Expected resultAble to continue editing. Actual resultFreeze/crash of Chrome. Other details (browser, OS, CKEditor version, installed plugins)Latest/nightly build: http://nightly.ckeditor.com/17-05-02-06-09/full/samples/ == |