Closed Bug 289248 Opened 20 years ago Closed 20 years ago

content window gets no scrollbars

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: ajschult784, Assigned: bzbarsky)

References

()

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

With a seamonkey gtk2 build, pages do not get scrollbars even if the window is
too small.  I saw this with a build from 19:54 PDT and 18:32 PDT, but not 16:50
PDT indicating the checkin from 286000 caused this.

I could not reproduce the problem with a firefox gtk2 build from 23:11 PDT
Saw this on Seamonkey at the same time Andrew did.

Unlike Andrew, however, I am also seeing this on Firefox GTK2 build (checkout
started 23:15 PDT)
I saw this problem in a just-pulled Firefox build (1am PDT, 4/6/05) on WinXP SP2.
OS: Linux → All
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050406
Firefox/1.0+

Confirming on Win
?1.1
Flags: blocking-aviary1.1?
*** Bug 289273 has been marked as a duplicate of this bug. ***
Valgrind is seeing this:

Conditional jump or move depends on uninitialised value(s)
 nsCSSFrameConstructor::CreateAnonymousFrames() (nsCSSFrameConstructor.cpp:5660)
 nsCSSFrameConstructor::BeginBuildingScrollFrame() (nsCSSFrameConstructor.cpp:6307)
 nsCSSFrameConstructor::ConstructRootFrame() (nsCSSFrameConstructor.cpp:4622)
 PresShell::InitialReflow() (nsPresShell.cpp:2810)
 nsContentSink::StartLayout() (nsContentSink.cpp:921)
 HTMLContentSink::StartLayout() (nsHTMLContentSink.cpp:3661)
 HTMLContentSink::OpenBody() (nsHTMLContentSink.cpp:2774)
 CNavDTD::OpenBody() (CNavDTD.cpp:3021)
 CNavDTD::OpenContainer() (CNavDTD.cpp:3250)
 CNavDTD::HandleDefaultStartToken() (CNavDTD.cpp:1316)
 CNavDTD::HandleStartToken() (CNavDTD.cpp:1695)
 CNavDTD::HandleToken() (CNavDTD.cpp:938)

I added this:
           aParent->GetNodeInfo() &&
           aParent->GetNodeInfo()->Equals(nsSVGAtoms::use, kNameSpaceID_SVG))
        bindingParent = aParent;
 #endif
       rv = content->BindToTree(aDocument, aParent, bindingParent, PR_TRUE);
+      fprintf (stdout, "rv=%d\n", rv);
       if (NS_FAILED(rv)) {
         content->UnbindFromTree();
         return rv;
       }

the first call returned rv = 5354252.  I added "rv=14;" before the call to
BindToTree, and it "works" now.  rv=0 always and I have scrollbars.  That smells
like a compiler bug, but that wouldn't explain someone seeing this on WinXP...
*** Bug 289293 has been marked as a duplicate of this bug. ***
Severity: critical → blocker
Flags: blocking1.8b2?
Attached patch Patch (untested) (obsolete) — Splinter Review
I presume only non-SVG builds are seeing this?

If MOZ_SVG is not defined, and any of the applicable if statements are true in
the MOZ_XUL and MOZ_XTF sections, then rv is never set since it effectively
falls into the else clause.

In the patch the additional |bindingParent = content;| effectively does
nothing, but that's the easiest way I can think of without using empty
statements.
Attachment #179850 - Flags: review?(bzbarsky)
Comment on attachment 179850 [details] [diff] [review]
Patch (untested)

Mook, nice catch!  And yes, all my builds were SVG builds....

This isn't quite the approach I think we should take here, though.  Different
patch coming up.
Attachment #179850 - Flags: review?(bzbarsky) → review-
Attached patch PatchSplinter Review
I think an empty block (with corresponding comment) is actually clearer here
(and lets me make the svg block like the others to prevent this from happening
again).
Attachment #179850 - Attachment is obsolete: true
Comment on attachment 179856 [details] [diff] [review]
Patch

r+sr+a=shaver for 1.1a checkin so that we work even without SVG.
Attachment #179856 - Flags: superreview+
Attachment #179856 - Flags: review+
Attachment #179856 - Flags: approval-aviary1.1a+
Blocks: 286000
Comment on attachment 179856 [details] [diff] [review]
Patch

Sorry, I meant 1.8b2, which I think eventually leads to 1.1a, but really...
Attachment #179856 - Flags: approval-aviary1.1a+ → approval1.8b2+
Fixed on trunk.  Thanks for figuring out what the problem was, guys!  And my
apologies for the trouble.
Oh, and people might want to remove the blocking nominations from this bug....
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050406
Firefox/1.0+ 10:18 PDT

verified on FF/Win
*** Bug 289342 has been marked as a duplicate of this bug. ***
*** Bug 289350 has been marked as a duplicate of this bug. ***
*** Bug 289408 has been marked as a duplicate of this bug. ***
*** Bug 289466 has been marked as a duplicate of this bug. ***
Target Milestone: --- → mozilla1.8beta2
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: