Page MenuHomePhabricator

Page not fully loading in edit window, leading to accidental blanking at foot of articles
Closed, ResolvedPublic

Description

Author: wikiredvers

Description:
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).


Version: unspecified
Severity: major
OS: Windows XP
Platform: PC
URL: http://en.wikipedia.org/w/index.php?title=Channel_Tunnel&diff=prev&oldid=49032629

Details

Reference
bz5643

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:12 PM
bzimport set Reference to bz5643.
bzimport added a subscriber: Unknown Object (MLST).

Can you:

  1. Describe how to reproduce this situation?
  2. Tell us which browsers are in use?

wikiredvers wrote:

  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).

  1. 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?

wikiredvers wrote:

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.

paul.austin wrote:

Same as Redvers

i have Firefox 1.5.0.2 and Opera 8.00 on Windows XP SP2

beesley wrote:

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

beesley wrote:

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.

robchur wrote:

(In reply to comment #8)

Will attempt to repro. with those conditions in a moment, if someone doesn't
beat me to it first.

sannse wrote:

Uninstalling the Google toolbar seems to have stopped it

david wrote:

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.

Yskyflyer wrote:

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

wikiredvers wrote:

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?

davidcraig5 wrote:

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.

davidcraig5 wrote:

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.

davidcraig5 wrote:

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.

Yskyflyer wrote:

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.

robchur wrote:

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.

askoorb wrote:

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.

kjoonlee wrote:

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.

mets501wiki wrote:

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.

william-bugzilla.wikimedia.org wrote:

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.

william-bugzilla.wikimedia.org wrote:

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?

seahen123 wrote:

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?

william-bugzilla.wikimedia.org wrote:

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.

askoorb wrote:

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).

phil_knight wrote:

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.

jepe wrote:

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.

askoorb wrote:

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.

episcopalkid wrote:

This is happening to me, too. Only on REALLY long pages, though. Just atarted
after I upgraded to SeaMonkey 1.0.3.

drew wrote:

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.

plasmeier180 wrote:

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.

ayg wrote:

Does Brion's minimal test case at http://test.leuksman.com/toolbar-tab-bug.html
no longer show the bug either?

plasmeier180 wrote:

(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.

ayg wrote:

This is about as FIXED as it can be, then, I suppose.