Closed Bug 388787 Opened 18 years ago Closed 16 years ago

[1.8 branch] Long (tall) pages in Mediawiki display incorrectly

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
1.8 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: devn3t, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070531 Firefox/2.0.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070531 Firefox/2.0.0.4 This is a Linux only bug. I have tested this out in Windows with no problems. Latest version of Opera displays this fine. Konqueror in KDE 3.5.7 displays this page fine. Firefox in Windows displays this fine (latest version as of the date of this ticket for all browsers discussed). The page breaks apart and drops its CSS. Notice that this only happens on longer pages inside the Wiki and only happens in Firefox (latest) in Linux. Reproducible: Always Steps to Reproduce: 1. Open Page in Firefox on Linux 2. Notice the improper display of the page. 3. Actual Results: Improperly displayed web page Expected Results: Properly displayed web page
Can you reproduce with a local copy of the page? Can you make a reduced testcase that demonstrates the bug?
I am unable to produce a local copy of the page as I do not have access to this server/database. I know that there is a page on our internal facing wiki that also suffers from this same symptom. Both pages are extremely long and contain multiple template calls {{}}.
You should be able to save a local copy for reduction purposes using File > Save As... .
Jesse, I can save that fine, but the CSS will be stripped out...which pretty much eliminates any reproducibility for this bug.
To keep the CSS working, use "save as complete" or add a <base href> tag after saving just the HTML.
I don't have the option to "save as complete". I have no idea what "add a <base href> tag after saving just the HTML" means.
> I don't have the option to "save as complete". The "Save As..." dialog should have a dropdown, and one of the options should be something like "Web Page, Complete". That will cause Firefox to save the stylesheets along with the HTML. > I have no idea what "add a <base href> tag after saving just the HTML" means. After just saving the HTML ("Save As..." with "HTML only" selected), add this just inside the <head>: <base href="http://wiki.rpath.com/wiki/"> That will cause relative URLs to be interpreted as being relative to the correct URL (style sheets will still load from the server).
I have replicated this with a local copy of the page. Please let me know how you would like to proceed :) And thanks for helping me along the way here :D
Yay! Now can you edit that down to a minimal HTML+CSS testcase that causes the bug to happen for you? (Ideally, removing anything from the testcase should cause the bug to stop happening.) http://www.mozilla.org/newlayout/bugathon.html gives some hints about how to do that.
I've removed length from the page and found that by cutting the size in half, firefox now displays correctly. This is without touching the CSS/HTML at all. For me, this means that there is a rendering problem for the page. The only thing removed was standard mediawiki entries (text and maybe a table or 2).
BTW, when I say rendering problem for the page...it means I believe there is something wrong with firefox displaying the page as cutting the page length fixes the problem and it is able to be displayed in other browsers without the page length cut (using browsershots.org)
Could it be the large height that triggers the bug rather than the specific contents of each half of hte page? Perhaps you can replace a large chunk of the page with something like <div style="height: 4000px;"></div> as you're trying to make a reduced testcase.
Adding those divs to the page did not work. I'm absolutely sure it's the large height that triggers this in firefox. The question is why? All other web browsers (except epiphany) work fine with this page. Why would firefox place limits on page length...or rather, does it?
It's odd that you need the height to reproduce the bug, but you can't replace a bunch of content with a single tall div. Firefox doesn't intentionally set low limits on page length. Firefox trunk tries to work for something like 2^32 / 60 pixels (over a million lines of text). Sometimes bugs like this are due to calling lower-level APIs that expect apps to clamp to smaller numbers of pixels, e.g. 2^16 or 2^15 (see bug 335107 for an example of such a bug).
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7pre) Gecko/200708010404 Minefield/3.0a7pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/2007072517 Firefox/2.0.0.6 Looks good on trunk, broken on 2.0.
Severity: normal → major
Product: Firefox → Core
QA Contact: general → general
Summary: Long Pages in Mediawiki Display Incorrectly → [1.8 branch] Long (tall) pages in Mediawiki display incorrectly
Version: unspecified → 1.8 Branch
Glad to hear that it's not present in the newest builds :)
(In reply to comment #15) > Looks good on trunk, broken on 2.0. 2.0 has reached its end of life. If it works on 3.0, that's fine.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.