Closed Bug 61946 Opened 24 years ago Closed 24 years ago

scrollbars missing when mozilla is embedded

Categories

(Core Graveyard :: Embedding: GTK Widget, defect, P3)

Product:
Core Graveyard
Component:
Embedding: GTK Widget
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: blizzard, Assigned: hyatt)

Details

(Keywords: smoketest)

Some time in the last few days when you embed mozilla into another window it never has scrollbars. If you have a scrolling mouse you can still scroll the content area. Everything else looks OK. This is a major blocker for me and everyone using an embedded window. This doesn't just affect the gtk embedding widget it also affects gtkEmbed which doesn't use XUL to embed a browser. I need some help with this. I don't even know where to begin looking to solve this problem. Are the windows embedded clients busted too? I can't check.
dup of 61852 "Scrollbars are completely missing" *** This bug has been marked as a duplicate of 61852 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
I don't think this is a dup. In the browser the scrollbars work fine. It's only in the embedding case.
winEmbed is busted too; no scrollbars.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I've got a tree that I'm backing out to the 28th. I'll start narrowing it down from there. *sigh*
Starting from blizzard's comment to the hook that this was a change on Dec. 1, I tested release builds and found that the regression in gtkEmbed was between the releases of 2000-11-30-21-Mtrunk and 2000-12-01-08-Mtrunk.
Make that between 2000-11-30-21-Mtrunk and 2000-12-01-06-Mtrunk.
is this a blocker, or is the scrollmouse and/or keyboard scrolling enough of a workaround?
it's a blocker.
marking to show up on blocker radar.
Severity: critical → blocker
Keywords: smoketest
I'm guessing this *is* a dup of 61852. Scrollbars don't work in browser either, read that bug. Also see bug 61990.
are 61990 and 61946 both due to pinkerton's forms.css packaging issue late last week? I'm thinking he added the file(s) to the packages-* files, but that they are required for viewer and embedding but aren't being packaged with them. I know embedding has it's own packages-* files, but don't know how viewer is packaged.
i didn't realize we had embedding packages* files.
OK. It is definitely this checkin from hyatt: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=12%2F01%2F2000+00%3A01%3A00&maxdate=12%2F01%2F2000+00%3A30%3A00&cvsroot=%2Fcvsroot "breaking out html forms into their own stylesheet, a=ben@netscape.com" I'm going to guess that it's the changes to nsChromeRegistry.cpp. He doesn't load the scrollbar.css file if it can't find the user's profile directory. I know that the embed code doesn't initialize profiles. I don't know about viewer.
sending to hyatt. Who reviewed this stuff? It looks like there's only an a=ben.
Assignee: blizzard → hyatt
Status: REOPENED → NEW
hyatt + pink fixed it. thanks, guys!
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
I verified that this is vixed.
I initially thought this was a duplicate of bug 61852. I also thought 61990 was a dup of bug 61852. Bug 61852 is still reopened, but 61990 and this one are now marked fixed. Is it possible that the fix for 61946 and 61990 was really the fix for 61852? If so, perhaps someone should mark that one as fixed as well.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.