Opened 9 years ago

Last modified 3 years ago

#1226 new defect

[Confirmed] Hitting enter in certain documents causes the rest of the text to disappear in Firefox 3

Reported by: douglas Owned by: ejucovy
Priority: normal Milestone: 0.97
Component: Browsers_Firefox Version: trunk
Severity: blocker Keywords:
Cc: douglas

Description

Go to http://xinha.gogo.co.nz/xinha-nightly/examples/ExtendedDemo.html and in HTML mode, insert the followin HTML:
"General Resources<br />
<h3>mailing lists</h3>"

Go back to document view, click at the end of the first line and hit enter. The second line will disappear. This is because of a bug in FF3 where getSelection incorrectly reports a selection to the end of the iframe. This has been ticketed with Mozilla at:
https://bugzilla.mozilla.org/show_bug.cgi?id=437672

Hopefully they'll fix it before release so that we won't have to patch around their bug.

Attachments (1)

paraHandlerBest.js (62.9 KB) - added by ejucovy 3 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by gogo

  • Severity changed from major to blocker
  • Summary changed from Hitting enter in certain documents causes the rest of the text to disappear in Firefox 3 to [Confirmed] Hitting enter in certain documents causes the rest of the text to disappear in Firefox 3

Hi Douglas, I confirm this behaviour. Very nasty.

You indicate in the bugzilla track that it may be an issue in Xinha to be fixed?

I can reproduce the test case every time on many computers...  You have to go
to HTML mode before inserting the text, then return to document mode, but upon
further inspection, the algorithm behind this page is so poorly written that
I've come to believe it's miswritten, and is just dependent on the behavior
pre-Firefox3, even if that behavior is wrong.  I looked at the code differences
in Firefox, and it's a change in nsRange.cpp which looks like it is a valid
change (Before, trying to create a range in reverse resulted in an invalid
range.  Now, trying to create a range in reverse collapses the range...  I see
this as valid behavior, but I was hoping to wait till the end of the week to
finish my testing...

Were you able to determine a possible fix?

comment:2 Changed 9 years ago by gogo

This appears to be a bug in what was the ExtendedParagraphs? plugin, and is now modules/Gecko/paraHandlerBest.js

Workaround for now is to set editor.config.mozParaHandler = 'built-in'

comment:3 Changed 9 years ago by gogo

I meant EnterParagraphs of course.

comment:4 Changed 8 years ago by douglas

I've pretty much finished this one up... Just testing now...

comment:5 Changed 8 years ago by guest

How's the patch?

The built-in handler is quite poor, I'd love to get the normal mode back in Firefox...

comment:6 Changed 7 years ago by gogo

  • Cc douglas added

Douglas, what's the status of this please, are you able to contribute your rewritten code, or is this no longer a problem?

comment:7 Changed 7 years ago by gogo

  • Milestone changed from 0.96 to 0.97

comment:8 Changed 7 years ago by gogo

NB Confirm still present FF 3.5.8

comment:9 Changed 7 years ago by gogo

I see that Douglas who seems MIA ( :-( ) had been working on this in a branch.
http://trac.xinha.org/browser/branches/Ticket1226

comment:10 Changed 6 years ago by ejucovy

  • Component changed from Xinha Core to Browsers_Firefox
  • Owner changed from gogo to ejucovy

Yuck. Also present in FF 3.5.9, I'll try to take a look at Doug's branch..

comment:11 follow-up: Changed 6 years ago by ejucovy

Doug's branch comes with an automatic test suite, which is nice (and impressive ;)

I ran the test suite in FF 3.5.9 -- it produced 14 javascript errors in four failing tests (and a number of successful tests). I'll try to dig in and see if I can make sense of any of the remaining failures..

comment:12 Changed 6 years ago by ejucovy

By the way, to run the tests, just load up a Xinha editor with the branched copy of Gecko/paraHandlerBest.js, and then in a Firebug console type:

EnterParagraphs.RunTests(xinha_editors['myTextArea'])

comment:13 in reply to: ↑ 11 Changed 6 years ago by ejucovy

Replying to ejucovy:

Doug's branch comes with an automatic test suite, which is nice (and impressive ;)

I ran the test suite in FF 3.5.9 -- it produced 14 javascript errors in four failing tests (and a number of successful tests). I'll try to dig in and see if I can make sense of any of the remaining failures..

Actually, the test run produces different results the first time you run it on the page - 10 javascript errors, not sure which tests it's failing in. The second, and all following times, it produces the 14 errors in four failing tests. I'll focus on the first run..

comment:14 Changed 6 years ago by ejucovy

I made a few commits on the branch to clean up the error output, add another failing test case which I discovered by accident, and fix one test failure (a non-essential one unfortunately).

Changed 3 years ago by ejucovy

comment:15 Changed 3 years ago by ejucovy

Attachment corrects a few more (trivial) test failures which differed from the expected output only in presence/absence of &nbsp;s and <br>s that make no visual difference.

Note: See TracTickets for help on using tickets.