rich text editor no longer in designmode when navigating back

RESOLVED FIXED

Status

()

Core
Editor
--
major
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Tom L. Snyder, Assigned: peterv)

Tracking

({regression, testcase, verified1.8.1.15})

1.8 Branch
x86
Windows XP
regression, testcase, verified1.8.1.15
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.13 -
blocking1.8.1.15 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

1.42 KB, patch
Samuel Sidler (old account; do not CC)
: approval1.8.1.15+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
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
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. 
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Flags: blocking1.8.1.13?
Keywords: regression
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → 1.8 Branch
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?
Keywords: qawanted

Comment 3

9 years ago
You have to check if you can still edit the text window after coming back.
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.
Blocks: 400556

Updated

9 years ago
Created attachment 305014 [details]
testcase

Updated

9 years ago
Keywords: qawanted → testcase
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...
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.
It's only the bf-cache that fails.
Does this regression from 400556 indicate more things may have also regressed?
Assignee: nobody → peterv
Flags: wanted1.8.1.x+
This WFM on [Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022509 Minefield/3.0b4pre].
(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.
(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.
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.
Flags: blocking1.8.1.14?
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.13-
Daniel, can you get MoCo resources assigned to this?  It won't just fix itself...
(Assignee)

Comment 15

9 years ago
Maybe it's as simple as porting the patch from bug 403501 to branch.
Status: NEW → ASSIGNED
If it doesn't reintroduce security holes, it should be....

Updated

9 years ago
Blocks: 424615
(Reporter)

Comment 17

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

Comment 18

9 years ago
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.
(In reply to comment #15)
> Maybe it's as simple as porting the patch from bug 403501 to branch.

peterv: does that work?

Depends on: 403501
Flags: blocking1.8.1.15? → blocking1.8.1.15+
Peterv, do you have an update here? We're freezing in two days...
Whiteboard: [needs branch patch, backport 403501?]
(Assignee)

Comment 21

9 years ago
Created attachment 323895 [details] [diff] [review]
Branch port of attachment 291386 [details] [diff] [review]

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

Updated

9 years ago
Attachment #323895 - Attachment is patch: true
Attachment #323895 - Attachment mime type: application/octet-stream → text/plain
Whiteboard: [needs branch patch, backport 403501?] → [has patch, needs approval]
Basically whether bug 400556 or some variant reappears.
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
Attachment #323895 - Flags: approval1.8.1.15+
Whiteboard: [has patch, needs approval]
Keywords: checkin-needed
Whiteboard: [needs checkin on the 1.8 branch asap]
(Assignee)

Comment 24

9 years ago
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?
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.
(Assignee)

Comment 26

9 years ago
(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.
(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.
I tested only with teh nightly here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
(Assignee)

Comment 29

9 years ago
Hmm, turns I can reproduce but only in an optimized build.
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.
(Assignee)

Comment 31

9 years ago
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.
Attachment #323895 - Flags: approval1.8.1.15+ → review-
(Assignee)

Updated

9 years ago
Keywords: checkin-needed
Whiteboard: [needs checkin on the 1.8 branch asap] → [needs branch patch]
(Assignee)

Comment 32

9 years ago
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).
Whiteboard: [needs branch patch] → [needs checkin on the 1.8 branch asap]
(Assignee)

Updated

9 years ago
Attachment #323895 - Flags: review-
(Assignee)

Comment 33

9 years ago
I checked this in, probably should file a separate bug for attachment 305014 [details].
Whiteboard: [needs checkin on the 1.8 branch asap]
Attachment #323895 - Flags: approval1.8.1.15+
The "only in opt" thing worries me.  Sounds like reading uninitialized memory or something...
Patch checked into 1.8 branch.
Keywords: fixed1.8.1.15
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.
Keywords: fixed1.8.1.15 → verified1.8.1.15
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.
Attachment #305014 - Attachment is obsolete: true
So this bug is fixed, because this is a branch bug, and it is fixed on branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.