If you try to load the MSDN EnableMenuItem page, the frame which displays the details of that function flashes up briefly before vanishing, i.e. it renders once, then is replaced by a white box with no scroll frame. STR: 1. Load URL for EnableMenuItem(). 2. Observe that there's a big white patch where the frame which contains the function description of the function should be. This occurs on Windows Vista at least as far back as beta 3.

I also see lots of these assertion failures, they may be related: ###!!! ASSERTION: Must have frame for destination coordinate system!: 'aOther', file c:/work/src/head/mozilla/layout/generic/nsFrame.cpp, line 3392 ###!!! ASSERTION: No view on any parent? How did that happen?: 'Not Reached', file c:/work/src/head/mozilla/layout/generic/nsFrame.cpp, line 5229

I see this bug on Linux, as well. OS/Hardware --> All. If I drag the divider between the tree and the white area all the way to the left, then suddenly the EnableMenuItem content shows up.

The assertion is happening because in nsGenericHTMLElement::GetOffsetRect we call nsLayoutUtils::GetAllInFlowRectsUnion(frame, parent) with a null |parent| pointer. That said, this bug worksforme on current linux, assuming I understood it correctly; comment 0 is not that clear on what part of the webpage I should expect to be missing. Can someone who's seeing it create a minimal testcase, perhaps?

And the reason parent is null is that the frame is a fixed-pos div, looks like. So we walk the parent chain to the viewport, and then to null. That should be fixed, I think, but it might be a separate bug from this one...

I see the problem on Mac --- the actual content pane which is supposed to have the document text is completely blank.

OK, fixing those assertions was trivial, but it doesn't fix the actual bug :-(.

I guess our next step is to figure out when this regressed...

The actual page is a big mess of JS, overall kind of flaky :-(. horrible to reduce :-(.

Yeah, that's why I'd go for regression range first. Or perhaps get Martijn in on this?

What's happening is that left pane (class="leftSection") is float:left and the content pane (class="rightSection"), which is overflow:auto is failing to fit next to it, so is dropping all the way down below it out of view. It's width:auto so I'm not sure why it's not fitting.

It returns a min-width of about 1189px, so that'd be why it's not fitting... The available width is about 846px.

Oh, this is very interesting. I can reproduce with Firefox. My Seamonkey build from the same exact source doesn't show the problem.

The <pre> with the text Friend Declare Function EnableMenuItem Lib "user32" (ByVal menu As Integer, ByVal ideEnableItem As Integer, ByVal enable As enmEnableMenuItemStatus) As enmPreviousMenuItemStatus (all on one line) in it down in the id="ctl00_rs1_WikiContent_ctl01_EditorContainer_editor" div seems to be the issue over here. It's certainly too wide for that available width. I wonder what the difference with Seamonkey is...

OK, the culprit is that for this function there is "community content" titled "Possible VB9 Declaration", where the community member has included <pre>Friend Declare Function EnableMenuItem Lib "user32" (ByVal menu As Integer, ByVal ideEnableItem As Integer, ByVal enable As enmEnableMenuItemStatus) As enmPreviousMenuItemStatus<br></pre> So this is definitely another instance of fallout from bug 134706. How unpleasant.

I'm still a little confused about why Seamonkey isn't getting the problem, for what it's worth... That seems to have the same community content, and it just overflows (as it should). I wouldn't think the scrollframe's min-width would be affected by its kids. Why is it?

I guess that's because of bug 402567... But in any case, the width here should just be a block's auto width, so shouldn't depend on the intrinsic min-width, right?

OK, this happens in Seamonkey too; just had to make the left sidebar a lot bigger; presumably different font settings somewhere. So the world is at least sane. I guess as long as we're using the scrollframe intrinsic min-width to decide whether it "fits" and and as long as the intrinsic min-width is the same as that of the scrolled frame, this will happen.

So nothing to do for me, here, anymore, right?

Yeah, I think we're all set.

The bug just marked a duplicated of this was blocking1.9+, if I'm reading this correctly are we saying it's Microsoft's (or whoever designed the web page) fault this happens?

I must say (as I reported in the dupe bug) Firefox 2, Safari 3.1 and Opera 9.50 beta render it "correctly". But if it is a Microsoft's mess, it will not surprise me...

Now it works :-) You can mark this bug as fixed.

I can't remember the bug number, but dbaron fixed this.

If this was fixed by an actual code fix on our side, this shouldn't be tech evangelism.

(In reply to comment #24) > I can't remember the bug number, but dbaron fixed this. > For the record, that was the patch in bug 427129.