Last modified: 2006-09-03 21:46:04 UTC
http://en.wikipedia.org/w/index.php?title=Cuba&diff=prev&oldid=48936490 http://en.wikipedia.org/w/index.php?title=East_Germany&diff=prev&oldid=48824250 http://en.wikipedia.org/w/index.php?title=Chewbacca&diff=prev&oldid=48689251 These four diffs all show the error in progress over the past couple of days to different editors. There are also several other occasions where this has happened; these diffs all have one thing in common - the editors have apologised and expressed surprise, proving that this is not vandalism. Other occurances of it cause vandalism warnings to be issued to both registered and anon users, but it's not possible to tell for sure unless the editor in question retorts. This same error has happened to me in the main article space of en 'pedia, and on my user and talk pages, and to a template page, but after the first time it happened I've started to check the bottom of the edit window before saving to ensure the text is present. I'm assuming "critial" status applies as this is causing data loss (albeit /revertable/ data loss).
See also this diff http://en.wikipedia.org/w/index.php?title=Granada_Television&diff=49042031&oldid=49040850 that happened two minutes ago to me.
Can you: 1) Describe how to reproduce this situation? 2) Tell us which browsers are in use?
1) Two possible ways to attempt to reproduce. First, visit an en:Wikipedia article of some length (ie not a stub) and see if the article loads fully in the edit window when [edit this page] is clicked. I've just opened [[Cuba]] and the article stops suddenly at *[http://www.cubasolida If that doesn't reproduce it, make a small change at the top of the article and click [Preview]. I've just done that on [[Granada Television]] and the article stops suddenly at extravaganzas of its own, but was quite happy to transmit those produced by its co-franc Note that closing the page and revisiting it allows the full article to come up in the edit window, whilst hitting back and clicking [edit this page] again reproduces the same error (probably due to the browser cache). 2) I'm using Firefox 1.5.0.2 with Windows XP. Another affected editor is using Windows XP/Firefox and Windows XP/Opera.
Cannot reproduce problem with Firefox 1.5.0.2 on Windows XP SP2. Are you using a proxy server? Webwasher? "Virus checker" that insists on corrupting your web traffic?
No - direct connection. No - not that paranoid. No - just got ZoneAlarm Free between me and the interweb. I'll ask [[User:PMA]] the same questions and come back to you.
Same as Redvers i have Firefox 1.5.0.2 and Opera 8.00 on Windows XP SP2
I'm getting this en.wikipedia and wikia.com (both running MediaWiki 1.7 alpha). It's only been happening since I upgraded to Firefox 1.5.0.3 a few days ago. Sannse has the same problem on Wikia and also uses Firefox 1.5.0.3. The problem is NOT the page failing to load. The page does load. But, when you click edit in tab 1, then preview another page in tab 2, the content of the edit box in tab 1 gets cut off. It's completely reproducable. Examples: http://en.wikipedia.org/w/index.php?title=User_talk:Angela&diff=51825940&oldid=51726141 http://www.wikia.com/index.php?title=Template:List_of_Wikia&diff=35760&oldid=35759
I just realised that both sannse and I not only upgraded to Firefox 1.5.0.3 recently, but also we both installed the Google toolbar a few days ago. I think the problem started after that.
(In reply to comment #8) Will attempt to repro. with those conditions in a moment, if someone doesn't beat me to it first.
Uninstalling the Google toolbar seems to have stopped it
Forgive me if I'm rehashing old territory; I'm new here. Couldn't this be mitigated by passing along an MD5 hash with the section being edited and have a Javascript function validate the hash? I'm mentioning MD5 because a Javascript MD5 library already exists. At least in the vast majority of users' cases, they could be sure the section or article loaded properly.
For me I get this bug frequently when I edit a full page instead of a section or I edit a long section, but not always. I do use Google Toolbar for Firefox (Not the non Google imitation) but isn’t that a very common Program. How can you atribbue that extension to the problem? Anyway I use the Google spell checker in the toolbar on every edit so I can't afford to uninstall it. I just check every edit before I finally save specifically for this bug or any other formatting typo I make. I always preview first and if the bottom of the page gets deleted I just pres the back button and repress the preview button. Anyway I doubt it is a problem with the goggle toolbar because this is not a reproducible bug for my computer. I don't know how reproducible this bug is because when I edit a long page I preview several times. Sometimes I get the whole bottom cut off. Sometimes I don't. After I finish editing I check to one finial time and save. I do not think it is an issue when downloading but rather an issue when uploading. I say this because for me each time I view the preview and I see this bug I press back and the file did download the whole text. (Maybe I am talking about a different bug) For my computer it I think it is either my computer just doesn’t submit the whole thing or that Wikimidia doesn’t receive the whole thing. When the text gets sent to generate the page with the Preview and the editable text both come out the same so the problem is before then. But after the first time I get the text on my computer. Anyway another problem I get is when I download iTunes pod cast it stops in the middle and doesn’t recognize it stopped receiving data and I have to cancel and restart the download. Maybe it is a problem with our network. I use Optimum Online. Or maybe it is a bug with wikimida
There are some common themes starting to appear, from what I can tell. First, this bug shows itself most often when the servers are slow, or perhaps the local internet traffic. This suggests a timeout in Firefox rather than a MediaWiki issue. Second, it's not Google Toolbar. Uninstalling it hasn't helped me. However, Google Toolbar may contribute, as it uses a small bit of bandwidth. If the problem is bandwidth related, then this certainly won't help. Third, tabbed browsing comes into it. The problem is much more likely to appear if you click 'edit' and then switch to a different tab. Upon returning, the full page is cut off. Again, that suggests a bandwidth bottleneck - the other tab is doing something after all - and therefore a timeout in Firefox. Firefox has had a couple of incremental updates since this problem started to occur. I wonder if it's worth reporting it to Mozilla?
Same problem for me and a co-worker (has happened at home and at work) we both have FireFox 1.5.0.4 and the google toolbar. I have expericed it on the EN Minnesota article and EN featured pictures (though caught it beofre submitting), she experienced it here: http://en.wikipedia.org/w/index.php?title=Basilisk:_The_Kouga_Ninja_Scrolls&diff=prev&oldid=59515138. I am going to add these words to help people find this bug: cutoff, cut-off, missing text.
Sorry to spam, I can get this issues to happen on [[en:minnesota]] nearly every time. Again its FireFox 1.5.0.4 on WindowsXP and the google toolbar. I have cable internet. It does seem that choosing "open in new tab" when I edit exacerbates this problem. I will try installing an older version of firefox and see if the issues changes. If it does i'll check over there.
Again sorry to spam, but the issue is definitely related to firefox, I got the latest trunk (minefield) from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (on 06/22/2006) and the issue immediately disappeared. (note that it has no extensions) Should this bug be closed or should there be protections put in place to prevent this from happening?
Was that Minefield WITH Google Toolbar or Minefield WITHOUT Google Toolbar? Note that running the latest versions will usually disable most or all extensions.
Confirmed behavior is directly related to use of Google Toolbar. It works in Minefield because the toolbar extension is disabled; you can disable the extension in regular Firefox too and restore proper functionality. (Don't forget you have to *restart* the browser!) Mailed bug report to toolbar-feedback at google.com: ----- Hi Toolbar folks, We've gotten a slew of error reports in the last few weeks about pages on Wikipedia being mysteriously cut off during editing. Recently it's become apparent that it's associated with use of the Google Toolbar for Firefox. I've created a minimal test case page: http://test.leuksman.com/toolbar-tab-bug.html This sample page contains a simple <textarea> with about 38 kilobytes of text (512 lines). After switching away to another browser tab and back to the first one, the contents of the textarea are cut off partway through line 443. Tested with Firefox 1.5.0.4 on Windows XP SP 2 (x86). The error occurs only when the Google Toolbar is installed and enabled. Disabling the toolbar extension and restarting Firefox, the problem goes away. Reenable the extension and restart Firefox, and it comes right back. This problem is very disruptive to Wikipedia (and presumably other wikis and wiki-like systems where large text blobs are edited in-browser), as pages are frequently cut off and damaged unexpectedly, requiring repair. The issue in our bug tracker, for reference: http://bugzilla.wikimedia.org/show_bug.cgi?id=5643 We're going to try adding some kind of detection and warning when the toolbar is present, but we would very much appreciate it if you could look into the conflict and correct it. Thank you for your time. ------
Ok Great i Uninstalled the Google toolbar but now, How do i Spell check? Do you have any inbrowser Spellcheckers i can use untill this bug is fixed. I used Google Toolbar to spell check, now what do i do. I could copy and paste it into MS word but that is a little teadeious.
Please refrain from commenting on this bug unless you are a developer, acting under the instructions of one, providing even further information to narrow down the problem, or have a good workaround.
A potential workaround for this bug follows. There is an add-on for Firefox available at https://addons.mozilla.org/firefox/1022/ This add-on allows spellchecking using Aspell. Installation is not trivial and requires a working Aspell installation with an Aspell dictionary, but both of these can be acquired free. Quick installation instructions (for windows): Download the "full installer" and the English dictionary from http://aspell.net/win32/ and install them Go to https://addons.mozilla.org/firefox/1022/ install the extension and restart Firefox. AspellFox is now ready to use. To spell-check any text box just right click and choose “AspellFox”, a spell check box will open. You are still stuck without a Google Toolbar though, as the open source http://googlebar.mozdev.org/ has stalled development and does not work with Firefox 1.5.x I hope this helps.
I have run into similar problems with Firefox, but I'm not using Google Toolbar. I can post a list of my addons if you want.
Are you sure that Google Toolbar is uninstalled (not just hidden)? Go to tools-->extensions to make sure Google Toolbar isn't listed there. If it is there, then uninstall it. If it Google Toolbar is not listed, then you can post a list of your addons here.
I've done more research on this. I've got data, but a few conclusions first: 1. It's definitely the Google Toolbar. 2. The bug happens for pages where people are not currently seeing thewarning. 3. Google Toolbar makes tab-based editing of large pages VERY SLOW, so even if this bug were fixed, the toolbar has another issue where serious editors will want to disable it. 4. It's a weird bug. I tried editing a bunch of different pages to see how often the bug cropped up. Throughout I used Firefox 1.5.0.4 with Google Toolbar 2.0.20060606W on Windows XP Professional. For each page I tried, I started the browser, opened the page to be edited, then control- clicked "edit this page" twenty times, pausing roughly a second between clicks. If the text was truncated, it was always truncated in the same place for that page. I didn't always check a page without the Google Toolbar; that's represented by a dash below. Every time it got the page right, I counted that as a success. The results: size successes page title orig trunc diff goog nogoog ------------------------------------------------------------------- Talk:M.I.A. 7507 - 20/20 - Talk:Jack_Thompson (attorney) 13607 8193 5414 8/20 - Talk:Extreme Programming 42246 36865 5381 0/20 - Talk:Gregory Lauder-Frost 112960 106497 6463 3/20 20/20 Talk:Mail-order Bride 165138 159744 5394 2/20 20/20 As you can see, this is a little weird. It's odd that this only happens sometimes, and it's doubly odd that it always snips the same amount for a given page, but doesn't reliably snip. My sample size isn't large enough to tell how the problem is related to page size, but it is certainly happening on a page where nobody sees the warning right now. I also tried a variety of extention combinations on the Gregory Lauder-Frost talk page. Even with all extensions turned off but Google Toolbar, I got 1/20. Further turning off JavaScript, it was 5/20. Whenever I turned off Google Toolbar, it was 20/20, no matter what else I turned on. I hope that helps.
I have also checked to see if there's any server-side way to tell if the Google Toolbar is installed. Request headers are identical with the toolbar off and on, alas. Perhaps there's some way to detect it with JavaScript?
I think I may be noticing another common theme: cable Internet connections. I've been having this bug, and I'm on Rogers Yahoo! Comments 12 and 15, the only ones where people mention what type of connection they use, are also from cable users who have the bug. Maybe it's a connection problem specific to cable, and the Google Toolbar just disables the usual safeguards against this problem?
0123456789012345678901234567890123456789012345678901234567890123456789 Interesting question. I believe the bug is a client-side issue. It happens for me on DSL, and when I capture the raw packets, all the data passes over the wire properly. That's probably true for everybody; were the server reply being truncated you wouldn't see anything after the textarea. Also, at least for me, the Google Toolbar doesn't affect the HTTP or TCP envelope at all either on request or response, so I don't think the connection medium is involved in the problem.
UPDATE: Firefox 2.0 release candidate 1 is out now at: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/bonecho-beta1-candidates/rc1/firefox-2.0b1.en-US.win32.installer.exe (quick review here:http://www.trustedreviews.com/article.aspx?art=3140) Firefox 2.0 includes an integrated Spell Checker. I have not yet got Google Toolbar to install, co I cannot test that yet, but at least this is another work around. What is more, this is real time spell checking. Very nifty indeed. Before installing note that most extensions will not work (yet).
Hi, I have accidently cut the end of the Tenzin Gyatso article. Reverting doesn't restore the previous edit and I can't edit the older the versions to manually cut and paste. Sorry to have caused this and I 'll take a break from editting the article. I'm using internet explorer 5 on a mac, I haven't been using any special toolbars.
Please don't change all the information on a separate bug issue. Phil, Internet Explorer for Mac is one of those browsers that fails on long articles. That is why there is a big warning at the top of the page when you edit.
I have installed today a new version of the Google toolbar extension (2.1.20060713W) in Firefox 1.5.0.4 and this bug seems to be resolved. I have edited several long pages while switching tabs but the problem didn't appear.
Confirmed in FireFox 2.0 b1 with Google Toolbar version 2.1.20060713W. http://test.leuksman.com/toolbar-tab-bug.html no longer truncates at all. This new version of the Toolbar also appears compatible with the upcoming FireFox 2 release (as in it will run). However, whenever I try to use the Google Spell checker FireFox crashes out. FireFox's spell checker continues to work. Well, at least it is an improvement.
This is happening to me, too. Only on REALLY long pages, though. Just atarted after I upgraded to SeaMonkey 1.0.3.
Using Firefox 1.5.0.5, in a window with no tabs, no google toolbar, still having the page cut off after the edit. Switched to Safari, same problem. WORKAROUND: Copied everything in the edit window that followed my edit, previewed edit, pasted clipboard back in after edit, previewed again, and the end of the page was restored.
The EN Wikipedia page [[w:MediaWiki:Longpagewarning]] repots that the bug appears to have been fixed. From my experiences and recent testing, this seems to be the case. The last update to the Google Toolbar was 8/07/06. The version history page at Google was not updated since June. I have posted a message at the Google Group "GoogleToolbar Firefox Help > Something's Broken" (http://groups.google.com/group/FFToolbar-Group-Bugs?lnk=li) asking Google to update the Version History page.
Does Brion's minimal test case at http://test.leuksman.com/toolbar-tab-bug.html no longer show the bug either?
(In reply to comment #36) > Does Brion's minimal test case at http://test.leuksman.com/toolbar-tab-bug.html > no longer show the bug either? In my testing, using the latest version of the toolbar (2.1.20060807W) with the latest version of Firefox (1.5.0.6) on XP SP2, conducted now, the page is no longer cut off when switching tabs. When Brion's test case was first posted a while back, the page was cut off as I was using the Google Toolbar. To the best of my experience, it seems the problem was fixed. -Michael PS. I do not remember if the toolbar auto updated itself, or if I updated it in the Firefox Extensions window.
This is about as FIXED as it can be, then, I suppose.
