683151 - colemak.com - Wiki page Navigation pane/ page layout broken in Firefox 9

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect)

Description

[Stanley Chan]

Attachment: Screen shot of issue. (Firebug opened to highlight the div-container)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.866.0 Safari/535.2

Steps to reproduce:

Visit http://colemak.com/


Actual results:

The navigation pane is displayed to the bottom left.


Expected results:

The navigation pane should be displayed on the top right, right under the title image.

Comment 1

[Stanley Chan]

Attachment: This is how the page displays in Chrome Canary

Comment 2

[Stanley Chan]

This

Comment 3

[Stanley Chan]

This might actually be a Javascript bug as pointed out by http://forums.mozillazine.org/viewtopic.php?p=11195099#p11195099 -- 

Disabling NoScript does allow the page to display correctly. However, Chrome does no Javascript blocking and the page is still displayed as expected.

This might indicate an issue with the Javascript engine and NOT the Layout engine.


(Forgive my broken comment before -- I didn't know Bugzilla saved comments like that.)

Comment 4

[Boris Zbarsky [:bzbarsky]]

The behavior changed in this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6dc468c41136&tochange=f41df039db03

What's happening here is that the main content is a 100% width float.  The portlets are "overflow:hidden" blocks next to it, and overflow:hidden blocks can't overlap a float, so they get cleared down past it.  That said, this didn't use to break before the changes in that range...

Mats, could your text-overflow changes have affected this?

Oh, JS is only involved insofar as it sets overflow to hidden on the portlet.

Comment 5

[Mats Palmgren (inactive)]

Regression window on inbound:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b1844f9cf777&tochange=857f058efa56

good changeset: c3679628bee5
bad changeset: 857f058efa56	Matheus Kerschbaum — Bug 679971 - Remove Navigator.taintEnabled(); r=gal
http://hg.mozilla.org/integration/mozilla-inbound/rev/857f058efa56

Comment 6

[Mats Palmgren (inactive)]

http://colemak.com/wiki/skins/common/wikibits.js
var is_khtml = (navigator.vendor == 'KDE' || ( document.childNodes && !document.all && !navigator.taintEnabled ));

Comment 7

[Boris Zbarsky [:bzbarsky]]

Mats, good catch.  I sent them an e-mail with a pointer to this bug.

Comment 8

[Ed Morley [:emorley]]

I've just checked against the MediaWiki SVN and the offending line was removed in July 2009:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=53141&r2=53140&pathrev=53141

Therefore this would appear to be fixed in MediaWiki 1.16 and higher, according to:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/RELEASE-NOTES?r1=53141&r2=53140&pathrev=53141

Their news page (http://www.mediawiki.org/wiki/News) says 1.16 was released 2010-07-28.

Comment 9

[Stanley Chan]

Is there progress being made on this bug? Also, please forgive me if I misunderstand anything, but why exactly was the bug marked as tech evangelism..?

Another note: Here is another web page affected by this bug (most likely): http://www.biosector01.com/wiki/index.php?title=Main_Page

Comment 10

[Boris Zbarsky [:bzbarsky]]

Stanley, the bug needs to be fixed in the page, not in Gecko.  The page contains script that browser-sniffs assuming that we implement a certain non-standard feature, but we removed that feature.  So then the page decides that we're "khtml" and gives us markup that's designed to work around particular bugs that khtml has.... but we don't have those bugs.  So the layout ends up incorrect.

For progress to happen, you need to convince the page maintainer to fix their sniffing script or get rid of the sniffing altogether.  In this case, simply updating their MediaWiki installation to a current version would do the trick.

My attempt to contact them has resulted in no response from them so far.  Maybe you'll have better luck?

Comment 11

[Stanley Chan]

I see; I'll try and contact the site administrators when I get the chance -- thanks for making me understand the bug.

Comment 12

[j.j.]

See https://bugzilla.wikimedia.org/show_bug.cgi?id=31807

Comment 13

[Stanley Chan]

If it is possible, can this bug be marked as fixed? Seems that the page displays just fine now. (Probably because the sites have upgraded their wiki versions.)

Comment 14

[j.j.]

(In reply to Stanley Chan from comment #13)
> If it is possible, can this bug be marked as fixed? Seems that the page
> displays just fine now. (Probably because the sites have upgraded their wiki
> versions.)

... or due backout of "taintEnabled" removal in bug 679971?
-> WFM