Last modified: 2007-02-21 13:28:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T11044, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9044 - Pages loading slowly in Internet Explorer on Macintosh
Pages loading slowly in Internet Explorer on Macintosh
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
Macintosh Mac System 9.x
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-02-21 00:15 UTC by Franny Wentzel
Modified: 2007-02-21 13:28 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Franny Wentzel 2007-02-21 00:15:30 UTC
For the last 36 hours or so Wikipedia will load a small amount of data and
"park" unrendered for a few minutes before finally rendering when using Internet
Explorer. This occurs even when scripting and style sheets are turned off and
when pages finally render they look the same as before this problem cropped up.

Buying a new computer is NOT an acceptable option.
Comment 1 Brion Vibber 2007-02-21 02:28:18 UTC
Confirmed with IE 5.2.3 on Mac OS 10.4.8 (MacBook Core 2 Duo).

Cached pages seen before logging in seemed ok, as do logged-in views on my local
test site, but I can confirm the hanging behavior on after
logging in.

Probably related to the changes to compression and/or Content-Length header,
will have to experiment a bit to find the cause.
Comment 2 Brion Vibber 2007-02-21 09:20:51 UTC
As far as I can tell, the problem is that IE/Mac handles empty (zero-length)
files *very* poorly. It sits around waiting for more data that never comes in,
and eventually times out.

When you're logged in on Wikipedia, a custom stylesheet page for your account is
loaded; if you haven't put something into it it will be empty, triggering this

Note that the style sheet is *loaded* even if styles are disabled in IE.

The timeout has probably been made worse/slower by changes to the server
infrastructure, though I'm not sure exactly what; it doesn't seem to be
dependent on the Content-Length header. I do see the timeout behavior (with a
much shorter, but still noticeable, timeout) on my local test server when
$wgAllowUserCss is enabled in the site configuration, and it doesn't seem to be
dependent on the newly-added Content-Length header; I get the same behavior when
removing the header or on the 1.9 release which doesn't send it.

As a workaround until I can work out an appropriate fix, you can put a comment
into the style page, eg:

Put "/* */" or similar in the page; that will make it non-empty, avoiding the
bug, but won't cause any change to your display.
Comment 3 Rob Church 2007-02-21 09:23:15 UTC
Couldn't we work around this further by injecting some sort of comment into the
output where the custom CSS/JS files don't exist?
Comment 4 Brion Vibber 2007-02-21 09:26:18 UTC
In theory, yes. For instance as a special-case behavior when using css or js
content types for output... that would avoid breaking action=raw loads for
fetching pages, eg for editing.
Comment 5 Brion Vibber 2007-02-21 09:41:01 UTC
Yeah, seems to work ok. Gone ahead and committed that as r20018.

Franny, the site should work correctly for you now without you having to do any
special workarounds.
Comment 6 Franny Wentzel 2007-02-21 13:28:56 UTC
Confirmed working now.

Note You need to log in before you can comment on or make changes to this bug.