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
Last Resolved: 18 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
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, firstname.lastname@example.org" 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
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
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.
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.