Closed
Bug 289248
Opened 20 years ago
Closed 20 years ago
content window gets no scrollbars
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: ajschult784, Assigned: bzbarsky)
References
()
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
1.25 KB,
patch
|
shaver
:
review+
shaver
:
superreview+
shaver
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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
Comment 1•20 years ago
|
||
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)
Comment 2•20 years ago
|
||
I saw this problem in a just-pulled Firefox build (1am PDT, 4/6/05) on WinXP SP2.
Updated•20 years ago
|
OS: Linux → All
Comment 3•20 years ago
|
||
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?
Reporter | ||
Comment 5•20 years ago
|
||
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...
Updated•20 years ago
|
Severity: critical → blocker
Flags: blocking1.8b2?
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)
Assignee | ||
Comment 8•20 years ago
|
||
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-
Assignee | ||
Comment 9•20 years ago
|
||
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 10•20 years ago
|
||
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+
Comment 11•20 years ago
|
||
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+
Assignee | ||
Comment 12•20 years ago
|
||
Fixed on trunk. Thanks for figuring out what the problem was, guys! And my apologies for the trouble.
Assignee | ||
Comment 13•20 years ago
|
||
Oh, and people might want to remove the blocking nominations from this bug....
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Comment 14•20 years ago
|
||
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 289350 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Target Milestone: --- → mozilla1.8beta2
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•