547396 - After updating to 3.6, the Wikipedia "preview" button now occasionally deletes my edits

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Andrew Gradman]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6

Upon hitting preview, I am shown a preview as if my edit had consisted of me deleting all the text in the editing window.  When I attempt to recover my text by hitting "back" in the browser, I am shown the edit window prior to my edits.  Thus my edits are irretrievably lost.  This has happened three times today, and I am too dispirited to type any more words into webforms, goodnight.

Reproducible: Always

Comment 1

[Andrew Gradman]

I wish to amend my bug report -- this bug is not reproducible "always", but only inconsistently.

Comment 2

[Matthias Versen [:Matti]]

Do you mean bug 547239 ?

Comment 3

[Andrew Gradman]

(In reply to comment #2)
> Do you mean bug 547239 ?

I confess that I'm unfamiliar with the technical language, but yes, bug 547239 does look like my bug. -andrew

Comment 4

[Andrew Gradman]

I'm now marking this bug as a duplicate of bug 547239.  This is my first time using bugzilla so please correct me if i did this wrong.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Andrew, this is not a duplicate of bug 547239 unless you see a "confirm this redirect" dialog when normally doing a preview (or at least sometimes in Firefox 3.6), then you are NOT seeing this bug.

If you're willing to keep a log of your HTTP session while doing some editing following the directions at http://www.mozilla.org/projects/netlib/http/http-debugging.html and quit your browser as soon as the bug appears, then attach the log here, that would be much appreciated.

Comment 6

[Andrew Gradman]

Boris, thanks for undoing my erroneous markup.

Unfortunately, I'm bad with computers and couldn't follow the http session logging instructions.  This is probably a bottleneck that's affecting other novices as well, so if you can think of an effective place for me to send the following feedback, please let me know and I'll send it along.

First, I don't know how to compile stuff, so it would be nice if the " nightly trunk build " hyperlink first took me to page explaining how to do this.

Second, I've never used the OSX terminal before, and I couldn't figure out how much text I was supposed to copy-paste at each iteration.  It would be nice if the large box full of code were replaced with instructions like, "Copy-paste each of the following four lines of code into your terminal, hitting enter between each," followed by four separate code boxes isolated by bullet points. (If this sounds absurdly childish, you might make it a separate page called "absurdly childish version of these instructions".)

As someone who's made several thousand wikipedia edits and never touched Firefox until today, I can't help but be reminded of this graph ... http://wikip.blogspot.com/2005/08/future-of-open-source-5-years-ago.html 

:) cheers,

andrew

Comment 7

[Andrew Gradman]

OK, I found the Google Group for mozilla.dev.mozilla-org and reproduced my previous post there.  I plan to start logging my http session just as soon as I figure out how to do so.  :)

http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/37aec058f1f02931#

Comment 8

[Boris Zbarsky [:bzbarsky]]

> First, I don't know how to compile stuff, so it would be nice if the " nightly
> trunk build " hyperlink first took me to page explaining how to do this.

That part isn't actually up to date.  Any Firefox build (release, nightly, whatever) will work for doing the logging.

I agree that the instructions for OSX assume a good bit more knowledge than is relevant.... and the problem is at least in part that the precise directions differ by OS and Firefox version.  It doesn't help that those instructions are for the old Mozilla suite....

For Firefox 3.6 and OS X 10.5, the exact thing to copy/paste depends on where Firefox is installed on your system.  I'm going to assume it's installed on your desktop.  You want to copy and paste the following lines into Terminal, with Firefox _not_ running, and hit enter after each line:

  export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5
  export NSPR_LOG_FILE=~/Desktop/log.txt
  cd ~/Desktop/Firefox.app/Contents/MacOS
  ./firefox-bin

Then do some editing until you reproduce the problem.  As soon as it reproduces, quit the browser, and attach the log.txt file on your desktop to this bug.

If Firefox is installed in /Applications, not on your desktop, then replace the third line above with:

  cd /Applications/Firefox.app/Contents/MacOS

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, and if you run into any trouble with those instructions please comment here or mail me directly, ok?

One more question.  Do you have any extensions installed?  Especially Firebug or other extensions that would monitor your HTTP connections.

And thank you for helping dig into this!  We've had several reports of this problem, as far as I can tell, but they're all intermittent and hard to pin down.  :(

Comment 10

[Andrew Gradman]

Attachment: http log in which I reproduce the problem

This is an http log of the following activities:

I opened Firefox.  The default page happened to be the Wikipedia Sandbox in "edit" mode.  I was editing this revision, http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&direction=prev&oldid=345765800 , so the page looked like this, except it was not an "old revision":  http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&oldid=345765263 .

I typed some stuff into both the body-text and edit-summary fields.

I hit preview, and the preview displayed as follows: the body-text, edit-summary, and of course the preview of the page itself were all blank.

Then I quit.

Comment 11

[Andrew Gradman]

Boris, thanks so much for writing me customized instructions for how to create an http log!  I hope this helps.

RE extensions: I have tons of extensions installed, but nothing that seems particularly meddlesome:  Adblock Plus, All-in-One Sidebar, AutoPager, Easy Youtube Video Downloader, Echofon, ... ah, this might be TMI.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Andrew, one more question.  Is your Firefox profile or OS possibly set up to use a proxy, or proxy autoconfig or anything like that?

Comment 13

[Boris Zbarsky [:bzbarsky]]

As far as extensions go, can you check whether the problem also appears if you run in safe mode?  http://support.mozilla.com/en-US/kb/Safe+Mode has instructions on how to start in that mode.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Actually, nevermind comment 12 and comment 13.  I somehow failed to read the log before making those.

Looking through the log, here's the failing form submit:

-1608034528[300aa30]: http request [
-1608034528[300aa30]:   POST /w/index.php?title=Wikipedia:Sandbox&action=submit HTTP/1.1
-1608034528[300aa30]:   Host: en.wikipedia.org
-1608034528[300aa30]:   User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 GTB6
-1608034528[300aa30]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-1608034528[300aa30]:   Accept-Language: en,de;q=0.7,en-us;q=0.3
-1608034528[300aa30]:   Accept-Encoding: gzip,deflate
-1608034528[300aa30]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-1608034528[300aa30]:   Keep-Alive: 115
-1608034528[300aa30]:   Connection: keep-alive
-1608034528[300aa30]:   Referer: http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit
-1608034528[300aa30]:   Cookie: edittoolscharsubset=0; enwiki_session=854ac003aa70fb0a9926a37eeef5f6f1
-1608034528[300aa30]:   Content-Length: 0
-1608034528[300aa30]: ]

So no data being sent.  There's definitely some sort of proxy around somewhere here (looks related to Google Toolbar based on the log), so that might be causing it....  Andrew, would you be willing to run a test build I create with some additional logging added that might help pin down the problem?

Comment 15

[Andrew Gradman]

Sure, I'd be happy to.

Comment 16

[Boris Zbarsky [:bzbarsky]]

I've kicked off a build.  It'll be up at https://build.mozilla.org/tryserver-builds/[e-mail]-try-ea4104237bc1/ once it's done; probably 3-4 hours from now.

Comment 17

[Andrew Gradman]

"I've kicked off a build"?  I hope that is open-source-community-talk for, "I've got other people working on it," and not "I am working on it now."  3 or 4 hours sounds like a lot of work to do at this particular moment in the MIT time zone!

Comment 18

[Boris Zbarsky [:bzbarsky]]

"kicked off a build" in this case means "sent the code for Firefox 3.6 plus some small logging changes off to an automated system that will create builds and put them in that directory on build.mozilla.org".   And now I'm going to in fact go to sleep. ;)

Comment 19

[Boris Zbarsky [:bzbarsky]]

Andrew, the build to test is at https://build.mozilla.org/tryserver-builds/[e-mail]-try-ea4104237bc1/try-ea4104237bc1-macosx.dmg

Comment 20

[David Boswell]

In terms of making the documentation better for other people trying to do this, is the HTTP Logging page on the Developer Center more current (it seems like it from the time stamps).  If it is, let's redirect the page on mozilla.org to the newer one and it will be easier to edit there since it's a wiki.

https://developer.mozilla.org/en/HTTP_Logging

Comment 21

[Boris Zbarsky [:bzbarsky]]

Ah, yes.  That page is more current, yes.  It's just not the one that comes up first in google search for "mozilla http debugging".  ;)

Comment 22

[David Boswell]

OK, great.  I'll redirect that old one.

Unfortunate that the old docs are still showing up in searches, but that's a good reason to archive or migrate things.  If you'd like to look through other old netlib docs on mozilla.org, please feel free to comment on bug 501174 with any other pages to delete or redirect.

Comment 23

[Andrew Gradman]

Boris and David:  I'm very happy to see that https://developer.mozilla.org/en/HTTP_Logging is a wiki; I feel right at home!  I made some changes to the page which I hope will be helpful.   I do want to draw your attention to what I have labeled as "step three" and "step four" for each of the three builds (Windows, Linux, OSX).  First, I want to verify that I have not mischaracterized the last line of code as being equal to an instruction to "open Firefox".  Second, if this is accurate, I would recommend that we remove that line and simply tell people to "open Firefox."  It's more foolproof that way (we don't have to account for variations in where people have installed their Firefox).

Comment 24

[Andrew Gradman]

Boris, here's what I did:  I downloaded the .dmg file, closed Firefox, double-clicked the download, opened the "Namoroka" program, and went to the Wikipedia sandbox to test it out.

When I hit preview, I got the same bug.

If you'd like, I can log my http session for Namoroka as well, I just need to know if I have to make any changes to the HTTP logging instructions when doing this.  FYI, I have installed Namoroka to my desktop.

Comment 25

[Matthias Versen [:Matti]]

Andrew: The build shouldn't fix the issue.
from bz "Andrew, would you be willing to run a test build I create with
some additional logging added that might help pin down the problem?"

Please create a log with this build and attach it.

Comment 26

[Boris Zbarsky [:bzbarsky]]

> If you'd like, I can log my http session for Namoroka as well

Yes, that's exactly what I want.

> make any changes to the HTTP logging instructions

Just replace "Firefox.app" with "Namoroka.app" in the instructions.  The rest should work exactly the same way.

Thank you again!

Comment 27

[Boris Zbarsky [:bzbarsky]]

> Second, if this is accurate, I would recommend that we remove that line and
> simply tell people to "open Firefox."

Firefox has to be opened from inside the shell where the environment variables were set in this case.  Just double-clicking the icon won't do the right thing.

Comment 28

[Andrew Gradman]

Attachment: Namoroka build log

Here is a log using BZ's Namoroka build.  FYI, in this instance, within Wikipedia I actually hit "Save" rather than "preview," but it actually took me to a Preview screen containing the same bug (blank edit field).

Comment 29

[Boris Zbarsky [:bzbarsky]]

Perfect, thanks.  Relevant bits from the log are as follows.  The failing submit:

-1608034528[4e0aa50]: nsHttpChannel::SetupTransaction [this=22f27f30]
-1608034528[4e0aa50]: Creating nsHttpTransaction @229bb4e0
-1608034528[4e0aa50]: nsHttpTransaction::Init [this=229bb4e0 caps=1]
-1608034528[4e0aa50]: http request [
-1608034528[4e0aa50]:   POST /w/index.php?title=Wikipedia:Sandbox&action=submit HTTP/1.1
-1608034528[4e0aa50]:   Host: en.wikipedia.org
-1608034528[4e0aa50]:   User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100222 Namoroka/3.6 GTB6
-1608034528[4e0aa50]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-1608034528[4e0aa50]:   Accept-Language: en,de;q=0.7,en-us;q=0.3
-1608034528[4e0aa50]:   Accept-Encoding: gzip,deflate
-1608034528[4e0aa50]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-1608034528[4e0aa50]:   Keep-Alive: 115
-1608034528[4e0aa50]:   Connection: keep-alive
-1608034528[4e0aa50]:   Referer: http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=submit
-1608034528[4e0aa50]:   Cookie: edittoolscharsubset=0; enwiki_session=12e74eb4478bed12fe709bf5a0f7273c
-1608034528[4e0aa50]:   Content-Length: 0
-1608034528[4e0aa50]: ]

The place where we set up that nsHttpChannel:

-1608034528[4e0aa50]: DoReplaceWithProxy from @1fc36650 [pi=0]
-1608034528[4e0aa50]: nsHttpHandler::NewProxiedChannel [proxyInfo=0]
-1608034528[4e0aa50]: Creating nsHttpChannel @22f27f30
-1608034528[4e0aa50]: nsHttpChannel::Init [this=22f27f30]
-1608034528[4e0aa50]: host=en.wikipedia.org port=-1
-1608034528[4e0aa50]: uri=http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=submit
-1608034528[4e0aa50]: Creating nsHttpConnectionInfo @229be0f0
-1608034528[4e0aa50]: SetupReplacementChannel from @1fc36650 with @22f27f5c [preserveMethod=1]

So this is the case where we start off trying a proxy and then fall back on not having one.  That codepath is definitely broken, and the patch in bug 547239 should fix it.  I'll try to get a build with that patch done tonight.

Note that 0x22f27f30 - 0x22f27f5c == 0x2c, which is about what I'd expect on 1.9.2 if the destination channel passed to SetupReplacementChannel is an nsHttpChannel.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Andrew, https://build.mozilla.org/tryserver-builds/[e-mail]-try-f1c9643ad5a6/ should have builds with a possible fix for this bug if you want to try them.

Comment 31

[Andrew Gradman]

(In reply to comment #30)
> Andrew,
> https://build.mozilla.org/tryserver-builds/[e-mail]-try-f1c9643ad5a6/
> should have builds with a possible fix for this bug if you want to try them.

Thanks Boris!

Also, thanks for helping me submit my first bug report (big first steps!!); I've seen your name a lot in connection with Mozilla and I'm glad I got to work with you.  I'm going to unsubscribe from this bug, now that you've labeled this bug as "dependent" on bug 547239.  Good luck with all your work.  -andrew

Comment 32

[Boris Zbarsky [:bzbarsky]]

Andrew, I'm not sure there's a good way to "unsubscribe" from being a bug's reporter.

In any case, if you do get a chance to try that test build, please let me know whether it fixes your problem.   I'm going to leave this bug open until then.

Thank you again with helping get this sorted out!

Comment 33

[Andrew Gradman]

Woops, my mistake.  I downloaded this build; and it did fix the problem.

Unless you say otherwise, I'm going change the title of this new build from "Namoroka" to "Firefox", and move it to my applications folder (which will replace & thus delete the version that's already there).

andrew

Comment 34

[Boris Zbarsky [:bzbarsky]]

> I downloaded this build; and it did fix the problem.

Excellent, thank you!  Since that patch is checked in to the development tree, marking this bug fixed.

The one major caveat with using that build as "Firefox" is that I don't think it will correctly auto-update when newer versions come out, since it's not a build the update system knows anything about.  So it would make it very easy to end up with a browser with a published security vulnerability...  It might be better to keep it as a separate binary and check the actual "Firefox" binary every so often for updates; the next update to Firefox 3.6 should have this fix.