416751 - rich text editor no longer in designmode when navigating back

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Tom L. Snyder]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

With the latest update of SeaMonkey from 1.1.7 to 1.1.8 and of Firefox to 2.0.0.12 a rich text editor is no longer in designmode when coming back to the page using Back or Forward button navigation.

This bug is not specific for the example implementation (see link below), it also happened with another rich text editor.

Reproducible: Always

Steps to Reproduce:
1. Load http://www.kevinroth.com/rte/demo.htm
2. Navigate forward using a link on the page
3. Come back with the Back button
Actual Results:  
The rich text editor is no longer in designmode

Comment 1

[Ria Klaassen (not reading all bugmail)]

Yes, confirmed, it is a branch regression between the last two versions. 
Regression window should be
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-11-27+17&maxdate=2008-02-01+22&cvsroot=%2Fcvsroot
When I search for the word "editor" the findbar finds Bug 400556. It is a very wide range with hundreds of bugs. 

Comment 2

[Daniel Veditz [:dveditz]]

qawanted: please find us a narrower regression range. First step would be to see if this regressed on Dec 17 due to the suspected bug 400556.

I'm not seeing a difference between step 1 and step 3. What am I looking for?

Comment 3

[Cacycle]

You have to check if you can still edit the text window after coming back.

Comment 4

[Ria Klaassen (not reading all bugmail)]

New regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-17+04&maxdate=2007-12-18+04&cvsroot=%2Fcvsroot
and it is indeed caused by Bug 400556.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Comment 6

[Boris Zbarsky [:bzbarsky]]

Like I said to David about two weeks ago:

--------------------------------------------------------------------
I thought that was already the existing behavior before my patch too (and it was in my testing).  Maybe it was on trunk but not branch?

See https://bugzilla.mozilla.org/show_bug.cgi?id=400556#c21 second *, second -.

Perhaps this was only not working on trunk?  I guess https://bugzilla.mozilla.org/show_bug.cgi?id=403501 was a trunk-only regression...  So maybe this actually used to work on branch.

Peter, do you think it would be safe to only tear down the editor on branch if we're firing unload? 
--------------------------------------------------------------------

Peter, would you mind looking at this?  I really don't know when I'll have time to dig into the editor code...

Comment 7

[Martijn Wargers (dead)]

Well, I just filed a bug - bug 419054 - that never seemed to work on trunk and branch.
I guess this bug shows a subtle difference or something.

Comment 8

[Ria Klaassen (not reading all bugmail)]

It's only the bf-cache that fails.

Comment 9

[Daniel Veditz [:dveditz]]

Does this regression from 400556 indicate more things may have also regressed?

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

This WFM on [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022509 Minefield/3.0b4pre].

Comment 11

[Martijn Wargers (dead)]

(In reply to comment #10)
> This WFM on [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre)
> Gecko/2008022509 Minefield/3.0b4pre].

Yes, that's because this is a regression on branch.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #11)
> (In reply to comment #10)
> > This WFM on [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre)
> > Gecko/2008022509 Minefield/3.0b4pre].
> 
> Yes, that's because this is a regression on branch.
> 

Yeah, I just realized, sorry about that.

Comment 13

[Daniel Veditz [:dveditz]]

As potentially annoying as this is, hitting back into a designmode editor is kind of an edge case and we can't hold up a security release for it. It's something we'd want and take a fix for, but unfortunately not blocking.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Daniel, can you get MoCo resources assigned to this?  It won't just fix itself...

Comment 15

[Peter Van der Beken [:peterv]]

Maybe it's as simple as porting the patch from bug 403501 to branch.

Comment 16

[Boris Zbarsky [:bzbarsky]]

If it doesn't reintroduce security holes, it should be....

Comment 17

[Tom L. Snyder]

This has not been fixed yet despite being a major bug. Please could somebody check into this.

Comment 18

[Cacycle]

I second this request! This is a major problem for users of rich-text-editors, (e.g. wikEd on Wikipedia) and should be fixed as soon as possible.

Comment 19

[Daniel Veditz [:dveditz]]

(In reply to comment #15)
> Maybe it's as simple as porting the patch from bug 403501 to branch.

peterv: does that work?

Comment 20

[Samuel Sidler (old account; do not CC)]

Peterv, do you have an update here? We're freezing in two days...

Comment 21

[Peter Van der Beken [:peterv]]

Attachment: Branch port of attachment 291386

This looks like it works. Bz, what should I be looking for wrt your comment 16?

Comment 22

[Boris Zbarsky [:bzbarsky]]

Basically whether bug 400556 or some variant reappears.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 323895 [details] [diff] [review]
Branch port of attachment 291386 [details] [diff] [review]

Approved for 1.8.1.15, a=dveditz for release-drivers

Comment 24

[Peter Van der Beken [:peterv]]

So the problem I have is that I can't reproduce the issue anymore, either on www.kevinroth.com or with attachment 305014 [details]. Did a completely clean rebuild and tried with a new profile. Anyone have steps that can still reproduce this with a branch build?

Comment 25

[Ria Klaassen (not reading all bugmail)]

Testcase and page still reproducible with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/20080607 BonEcho/2.0.0.15pre
When I click and select some text in the input field and press Back, it goes one page back instead of deleting the selected text.

Comment 26

[Peter Van der Beken [:peterv]]

(In reply to comment #25)
> press Back, it goes
> one page back instead of deleting the selected text.

Did you mean backspace? Not really sure how that relates to the STR from comment 0.

Comment 27

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #26)
After the steps from comment 0 the input field is no longer editable. The browser (e.g. the backspace key) reacts as if it is not in an input field.

Comment 28

[Ria Klaassen (not reading all bugmail)]

I tested only with teh nightly here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

Comment 29

[Peter Van der Beken [:peterv]]

Hmm, turns I can reproduce but only in an optimized build.

Comment 30

[Samuel Sidler (old account; do not CC)]

Peter, glad you found a way to reproduce it. Please land ASAP on the branch, regardless of current red, which is being worked on by IT/Build.

Comment 31

[Peter Van der Beken [:peterv]]

Comment on attachment 323895 [details] [diff] [review]
Branch port of attachment 291386 [details] [diff] [review]

Patch doesn't seem to fix the issue, I can still reproduce in an optimized build with the patch.

Comment 32

[Peter Van der Beken [:peterv]]

Grrr, the patch does fix the issue with the original STR, but doesn't fix the issue for attachment 305014 [details]. I verified that this doesn't regress bug 400556. I'll check this in as soon as I can (probably in 2 hours).

Comment 33

[Peter Van der Beken [:peterv]]

I checked this in, probably should file a separate bug for attachment 305014 [details].

Comment 34

[Boris Zbarsky [:bzbarsky]]

The "only in opt" thing worries me.  Sounds like reading uninitialized memory or something...

Comment 35

[Daniel Veditz [:dveditz]]

Patch checked into 1.8 branch.

Comment 36

[Al Billings [:abillings - ex-MoCo]]

Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/2008061104 BonEcho/2.0.0.15pre. This works now.

Comment 37

[Martijn Wargers (dead)]

Comment on attachment 305014 [details]
testcase

This testcase was no good, because it doesn't reflect the regression range that was given for this bug, so I'm marking this attachment obsolete.

I believe the testcase is basically what bug 419054 is about.

Comment 38

[Martijn Wargers (dead)]

So this bug is fixed, because this is a branch bug, and it is fixed on branch.