Closed Bug 430056 Opened 16 years ago Closed 16 years ago

Camino trunk (and Minefield) Breaks my Wiki Sidebar

Categories

(Core :: Layout, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dlcook0421, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.14) Gecko/20080409 Camino/1.6 (like Firefox/2.0.0.14)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.14) Gecko/20080409 Camino/1.6 (like Firefox/2.0.0.14)

Camino 1.6, Safari, Firefox and IE (for Windows) all display my Mediawiki Sidebar the way it should be, but the nightly for Camino breaks it.

Reproducible: Always

Steps to Reproduce:
1. Head over to http://daniel.cook.name/index.php?title=Main_Page
Attached image 1.6
Attached image 2.0a1pre
Flags: camino2.0a1+
A corresponding Firefox 3 nightly renders it exactly the same way. I would
guess that this is correct behavior, since there have been fixes to the way
too-tightly sized elements flow on the trunk; if you believe that this is
really a bug, rather than a page issue, please make a reduced test case
demonstrating it.

(Please don't set flags, by the way.)
Flags: camino2.0a1+
Sorry but that makes no sense to me.  It's always worked (for *every* browser) and now it doesn't.  What do you mean by "way too-tightly sized elements"?
In certain cases, elements that should not have been placed next to each other because they didn't actually fit were anyway in Gecko 1.8, but (correctly) no longer are in 1.9. Given the way the sidebar is positioned just below the content intended to be next to it, this may well be such a case.

Your example page has a ton of IE-specific styling, and Firefox and Camino behave the same way, so "every" here is just Safari; WebKit sometimes has bugs, so the fact that they handle it differently doesn't make the current behavior wrong.

Sending to core for triage, since whether it's a bug or not it's certainly not a Camino bug.
Component: Page Layout → General
Product: Camino → Core
QA Contact: page.layout → general
Version: unspecified → Trunk
-> Core::Layout
Component: General → Layout
Keywords: regression
QA Contact: general → layout
Summary: Camino Nightly 2.0a1pre Breaks my Wiki Sidebar → Camino trunk (and Minefield) Breaks my Wiki Sidebar
That behaviour changed between 20080128-04 and 20080129-04.
That is bug 134706.

Opera 9.27 and Opera 9.5b behave exactly the same as Gecko 1.9.
Attached file test case 1
Test case. The green block, with overflow:hidden drops below the right column (floated right, negative left-margin).
Attached file test case 2
Same as test case 1, but overflow is set to 'visible' on the green block.
Note how the text flows differently in the second green block.
Blocks: 134706
Not sure if this helps, but I found the part of my code that is now breaking my sidebar.  It's in main.css.  What I did was increase the width of the sidebar to accommodate my treeview.  But when the new Camino and Firefox render the page the increase in width causes the entire sidebar to push to the bottom.  Can someone recommend a workaround?  I know just enough about css and mediawiki to be dangerous.

main.css

Original

.portlet {
	border: none;
	margin: 0 0 .5em;
	padding: 0;
	float: none;
	width: 11.6em;
	overflow: hidden;
}

New

.portlet {
	border: none;
	margin: 0 0 .5em;
	padding: 0;
	float: none;
	width: 19.7em;
	overflow: hidden;
}
I have not heard anything regarding this and overflow:hidden in my css continues to drop below the column next to it in both Camino and Firefox.  Is this going to be fixed?
I finally dug in and spent enough time to find a work around for this behaviour.  Ironically it came from a CSS file that MediaWiki uses to work with IE7.  Once I added the following code to my main.css file, the new Firefox and Camino both work with overflow=hidden the way they used to.

#column-one {
   padding-top: 160px;
   position: absolute;
   left: 0;
   z-index: 4;
   width: 100%;
}
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: