Opened 10 years ago

Last modified 8 months ago

#1226 reopened 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: Ticket 1226 Related
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 5 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 10 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 10 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 10 years ago by gogo

I meant EnterParagraphs? of course.

comment:4 Changed 10 years ago by douglas

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

comment:5 Changed 9 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 9 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 8 years ago by gogo

  • Milestone changed from 0.96 to 0.97

comment:8 Changed 8 years ago by gogo

NB Confirm still present FF 3.5.8

comment:9 Changed 8 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 8 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 8 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 8 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 8 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 8 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 5 years ago by ejucovy

comment:15 Changed 5 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.

comment:16 Changed 8 months ago by gogo

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

[1335]

I was unable to reproduce the problem in the current FF 58 version I have installed, but despite this I've committed the last version of paraHandlerBest.js that ejucovy attached to this ticket.

I (nor my clients) use Firefox much so I don't really have a lot of experience of how well (or not) it works.

comment:17 Changed 8 months ago by gogo

  • Resolution fixed deleted
  • Status changed from closed to reopened

Oops, nope, rolling this back out in [1338]

The behaviour of #1612 becomes even worse when using this patch

  1. Open a Xinha editor with the following contents: <ul><li><span style="color: green">Lorem ipsum</span></li></ul>
  2. Move the cursor to just after the "Lorem ipsum" text
  3. Press enter

Before applying the patch, it doesn't work that badly to be a real problem, and if you cursor inside the span and hit enter it breaks the span into two lists items as it should.

After applying the patch, it really doesn't work well at all, the span gets really broken, the parts swapped, sometimes put in different list items and so forth.

comment:18 Changed 8 months ago by gogo

See #1675

comment:19 Changed 8 months ago by gogo

  • Milestone changed from 0.97 to Ticket 1226 Related
Note: See TracTickets for help on using tickets.