347003 - Message editor on thedailywtf.com forums causes an infinite reload loop when using back button

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Ger Teunis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060802 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060802 Minefield/3.0a1

Message editor on thedailywtf.com forums causes an infinite reload loop when using back button.

Reproducible: Sometimes

Steps to Reproduce:
1. Open the above mentioned URL (http://thedailywtf.com/forums/AddPost.aspx?PostID=69457)
2. Click on the thedailywtf logo on the top-left op the page
3. Click on the back button

Actual Results:  
The page will get caught in an infinite reload loop most of the times.

Expected Results:  
The page should load once.

Comment 1

[Ria Klaassen (not reading all bugmail)]

The oldest build where I've seen this until now was 12-Aug-2005-01.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Regressed between 2006-07-14 and 2006-07-18.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Hmm, didn't notice Ria's comment

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

The reason (sort of) why this bug is back:
https://bugzilla.mozilla.org/show_bug.cgi?id=343282#c19

Comment 5

[Martijn Wargers (dead)]

The regression range Smaug sees in comment 2 is due to bug 343282, that bug fixed bfcache to make that work again, but it isn't really the cause for this bug.
This bug can only be seen when bfcache is enabled.

Comment 6

[Ria Klaassen (not reading all bugmail)]

It was functional for some days after the patch of Bug 335251 indeed.
I don't see it in 1.9a1_2006071715 but the bug is present in 1.9a1_2006071721.
So it must be in here:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-07-17+14%3A00&maxdate=2006-07-17+22%3A00
I see it also in branch.
I have not yet seen it with bfcache to 0.

Comment 7

[Martijn Wargers (dead)]

This regressed (the real regression window) between 2005-08-11 and 2005-08-1:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-11+07&maxdate=2005-08-12+09&cvsroot=%2Fcvsroot

Comment 8

[Martijn Wargers (dead)]

Ok, backing out the patch for bug 301358 doesn't help, so I guess this is a regression from bug 296639, somehow.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The immediate reason for the looping is that nsEditingSession::EndDocumentLoad calls nsEditingSession::SetupEditorOnWindow which tries to call nsDOMWindowUtils::GetImageAnimationMode which throws because there is no prescontext in the docshell at the moment.  The document in the window has no presshell either.  So we get an error rv from SetupEditorOnWindow, at which point nsEditingSession::EndDocumentLoad sets up a timer to load about:blank in the docshell.  When this load completes, we call nsEditingSession::EndDocumentLoad and so forth.

So the _real_ problem, somehow, is that editing session expects to have a prescontext and we just don't have one.  Why do we still have an editing session, though?

A testcase would be really nice.  :(

Comment 10

[José Jeria]

Attachment: Testcase

1. Load testcase
2. Click on any bookmark, or the throbber to load another page
3. Press the back button

Note that the iframe needs to be in an element that has display:none

Comment 11

[Boris Zbarsky [:bzbarsky]]

So... we used to not set up editing at all for iframes with no presshell, until bug 262998 got fixed.

If editor can't deal with lack of a presshell, we should go back to throwing in that code (and tearing down the editing session if our presshell goes away).  If editor _can_ deal, we should just fix the codepath that throws in this case to work instead.   I just don't know enough about editor to figure out which way it wants to jump.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Daniel says that editor can't deal with lack of a presshell.  So what we should _probably_ do is that if designMode is enabled while we have no presshell, we should do nothing, and then _really_ enable it once we have a presshell...  This means a bit of surgery on SetDesignMode, an extra member to keep track of whether we should enable (?) and a way to detect when we have a presshell (perhaps the AddObserver call?  We could post an event there; when the event fires we instantiate the editor.  Or something.  Not sure what script access stuff is involved).

Speaking of which, doing that would break scripting of editor stuff in a display:none iframe.  But I guess that's the best we can do for now.  :(

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Without being clear if this is a regression from 1.5 (since one of the potentially causing bugs seems to have been taken for 1.8) or how commonly this will affect users, we're not able to block on this at this point.

Comment 14

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

This doesn't happen for me anymore, can we close this?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, works for me too.