Closed Bug 62762 Opened 24 years ago Closed 24 years ago

gtkEmbed and winEmbed don't have scrollbars

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: jud, Assigned: leaf)

Details

(Keywords: embed, smoketest)

Attachments

(1 file)

Patch to makefile
596 bytes, patch
Details | Diff | Splinter Review 
using the dist of embedding harnesses (*NOT* the embed apps that sit in your
mozilla bin dir), there are no scrollbars.
Severity: normal → blocker
Keywords: embed
Target Milestone: --- → mozilla0.6
->evaughan, moz0.8, cc bryner for possible Linux assistance
Assignee: hyatt → evaughan
Target Milestone: mozilla0.6 → mozilla0.8
I see this with today's win32 and linux embed tarballs delivered to mozilla.org.
*** Bug 62674 has been marked as a duplicate of this bug. ***
I'll check it out. Does anyone have and embed build? Or can you tell me how to
quickly build one?
Status: NEW → ASSIGNED
this is on Windows and Linux
OS: Linux → All
Hardware: PC → All
I just pulled and ran winEmbed and scrollbars do show up. Is this just and
optimized build problem?
did you run it from dist/bin or from the embed directory?  I forget how you
create the embedding directory but Jud can remind us I bet.

This is marked blocker and shows up in the embedding smoketests but does not
have the smoketest keyword.  Should this be holding the tree closed?  If so,
someone needs to add smoketest to the keywords line.
Optimized or not, an *embedding* build is *not* what gets dumped to your
dist\*\bin dir. To get an embedding build you have to do a full build of
mozilla, then goto the embedding\config dir and type "nmake -f makefile.win."
That will copy embedding libs/files to dist\*\Embed. From *there* you run
gtkEmbed or winEmbed depending on platform.
this is an embedding blocker and has not had any progress.  I'm holding the tree
for this til we know what's going on.
Keywords: smoketest
I am getting these builds from the following directory:

ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/

selecting "embed-i686-pc-linux-gnu.tar.gz" for linux
&
"embed-win32.zip" for windows
this is down to some makefile-fu and progress is being made. 

taking this bug, since i've done all the work.
Assignee: evaughan → hyatt
Status: ASSIGNED → NEW
based on talk with pink and hyatt, they're on this and checkins won't hurt, so
I'm lowering to critical to drop off the radar and opening the tree.  Hopefully
this will be fixed in tomorrow's embed builds.
doh.  actually lowering priority.
Severity: blocker → critical
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
resolving as fixed per hyatt
this is not fixed

still seen on 2000-12-26 embed-i686-pc-linux-gnu.tar.gz
&
2000-12-26 embed-win32.zip
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Still not fixed, this is a blocker, holding the tree closed.
Severity: critical → blocker
I tried to see when this bug started.  Unfortunately, I don't see scrollbars in
the oldest embed trunk build still on ftp.mozilla.org, 2000-12-11-11-Mtrunk.  I
don't even see them in the embed build from MN6 (2000-11-28-13-MN6).  So when
did this start?
MN6 builds are branch builds, not trunk builds.  It could be this bug was in the
branch for a long time prior to this showing up on the trunk.  twalker would be
the best source, but I'm pretty sure this just showed up on the trunk around the
date it was filed.
Turns out the embedding builds has never had scrollbars so this shouldn't be a 
blocker, downgrading to normal bug.
Severity: blocker → normal
It seems that the problem is that the embedding builds don't have
all-packages.rdf and all-skins.rdf in the chrome/ directory.  When I do my own
embedding build, these files are present.  (all-locales.rdf, user-locales.rdf,
user-skins.rdf, and installed-chrome.txt are also in the chrome directory in my
build but not in the distributed one.)
so the problem here is that mozilla\embedding\config\installedchrome.txt doesn't
get copied to mozilla\dist\*\Embed . Rather than using the manifest file, it's
copied in the makefile. I'm not sure why that isn't working for the nightly build.
It would be great to fix this, if it's not too difficult. It would enable us to
update our KMeleon browser by just dropping it into the embed directory. 'CCing
myself.
Grabbing ownership for this bug
Assignee: hyatt → adamlock
Status: REOPENED → NEW
How are the automated embedding builds being done at the moment? Is it by 
"nmake /f embed.mak build_small) or by going into mozilla/embedding/config and 
doing a "nmake /f makefile.win" from there? Why are there two methods?

I do know for certain why there are no scrollbars from the "nmake /f embed.mak 
build_small" route. It is because:

a) mozilla/xpfe/global is not built by embed.mak
b) The scrollbars.css is in the global package is provided by the current theme.

To get toolkit.jar (the global package) plus scrollbars.css we must build a 
theme, e.g. mozilla/themes/modern followed by building mozilla/xpfe/global. Once 
these two things you get scrollbars, plus a lot of other unnecessary junk.

I suspect the problem with mozilla/embedding/config/makefile.win method are 
because the contents of the copied installed-chrome.txt refer to jar files when 
the embedding installer doesn't copy the jar files, just selective non-jarred 
chrome.
currently a script goes to mozilla/embedding/config and does a "make" in there.

There are two methods because we're caught inbetween. Ideally the "embed.m(a)k" 
model is where we want to go, but we lack ownership there. the embedding/config 
model is the closest thing we have to "working."

If you want to own the top level embedding build makefiles, and solve this 
problem from there, more power too you! That's the best way to go anyway.
This embedding package is created *after* a full browser-suite build is 
complete, so all the files required ought to be there already... I think the 
installed-chrome.txt is more likely the problem in both cases, if we're 
selectively copying individual css/js files for the embedding package... is 
there some way to generate a new installed-chrome.txt to match just the bits we 
want, rather than using jar urls?
Not in both cases, just the mozilla/embedding/config case. The embed.mak problem 
is due to chrome modules not being built so files are missing. The config 
problem is the unjarred chrome files are there but installed-chrome.txt doesn't 
point to them.

I personally think an improved embed.mak is the right way to go - or to have a 
finer grain of control over what gets built by client.mak/mk. The themes/chrome 
in particular need to be factored out so that browser/mail/wallet/etc. specific 
chrome doesn't get built if it isn't needed.
installed-chrome.txt does indeed point to the right files, the problem is that 
installed-chrome.txt doesn't get copied to the mozilla/dist/*/Embed dir when 
embedding/config is built using leaf's script. Everything works great in a 
developer's build.
After a build my installed-chrome.txt file contains package entries pointing to 
.jar files. What does the one on the build machine say?

If it is the same then I don't see how it could work. The basebrowser-win & 
basebrowser-unix installers don't copy jar files, just contents of these 
folders:

chrome\toolkit\content\global\*
chrome\classic\skin\classic\global\*
chrome\en-US\locale\en-US\global\*

So there is no way winEmbed is going to find necessary chrome files because 
installed-chrome.txt says they are in a jar file when they're sitting in 
folders under chrome/. Perhaps the chrome "wacky default" code is correctly 
fixing up some stuff so it doesn't fail completely.

The possible solutions for this problem are to:

1) Generate a new installed-chrome.txt pointing correctly to the folders that 
really contain the chrome.
2) Create a jar.mn and package the files and folders into new cut-down jar files
3) Copy the client jar files and live with the bloat for the time being

Option 3 may be the most practical stop-gap solution since arguably embedding 
distributions shouldn't be created as a post client build step anyway.
Ignore what I just said there. I misunderstood where the 
embedding installed-chrome.txt was coming from. I'm investigating a bit 
further...
Leaf, it looks like everything is in working order both in debug and release 
builds when I build embedding the mozilla/embedding/config/makefile.win way.

Is it possible that an additional build step on the build machine means that 
some or all of the unjarred chrome files are not there to be copied? Do you 
clean out the chrome directory in any way for instance?

*smack*

I started doing the embedding package creation before it just worked out of the 
box, so we do the steps for package creation in the automation, rather than 
using the build system... since we are only using the manifest file, rather than 
running make in embed/config to produce the distribution area.

adam, you can reassign the bug to me since this is an automation problem.
I really liked Adams 2) suggestion about providing downsized .jars that only 
contain the files that are needed for embedding. If you are changing the 
automation anyway, could you consider doing this as well?
-> leaf. sebastian, please file a new bug.
Assignee: adamlock → leaf
seeing scroll bars on 2001-02-01 winEmbed

still not there for linux
OS: All → Linux
Hardware: All → PC
moving to mozilla0.9 as this doesn't have to be in mozilla 0.8 since it doesn't
impact mozilla, just the embedding wrapper.
Target Milestone: mozilla0.8 → mozilla0.9
I know why this is happening.

Do an 'ls -l' in $DIST/Embed/chrome and you'll see that installed-chrome.txt is 
symbolically linked to the one in mozilla/embedding/config. The symlink breaks 
in the embedding distribution and so there is no chrome.

This is because the mozilla/embedding/config/Makefile.in is using the $(INSTALL) 
macro and that is linking rather than copying the file. Perhaps we should use 
"$(NSINSTALL) -t" instead?




Yeah, we want to do a copy, not a link.


    
    

    
  
the link is fine, we just need to tell tar, when creating the package, that it 
should resolve links, i think. I'll look at the way the embedding package is 
created today.
Status: NEW → ASSIGNED

    
    

    
  
hyatt, can i take your comment as a r= for the $(NSINSTALL) -t change?

    
    

    
  
sometimes rules suck... cls, can i get an sr= for this patch?

    
    

    
  
I thought I'd given this one a sr before.  Let's try again.
sr=cls


    
    

    
  
I've checked in the fix for this.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
verified fixed on gtkEmbed 2001-02-28
Status: RESOLVED → VERIFIED

    
  
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: