PrintDialogPDE.plugin not included in OSX package

VERIFIED FIXED in mozilla1.0.1


Build Config
16 years ago
13 years ago


(Reporter: Chris Petersen, Assigned: J.J. Enser)



Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



16 years ago
Build: 2002-04-24-08
Platform: OS X 10.1.4
Expected Results:  Browser Printing Extensions should appear in Print dialog
drop-down menu.
What I got: Browser Printing Extensions is not listed in menu.
Basically, PrintDialogPDE.plugin is missing from the Essential Files directory
in of the browser package.

This problem started to occur with April 23rd trunk build.


16 years ago
Summary: PrintDialogPDE.pluginnot include in OSX package → PrintDialogPDE.plugin not included in OSX package

Comment 1

16 years ago
this is critical.. I was asked to put this onto the branch, I think this really 
needs to be working correctly on the trunk before I land it there.
Severity: critical → blocker


16 years ago
Keywords: regression
Priority: -- → P2

Comment 2

16 years ago
if this is "critical", then it should be marked as such (doing so now). do not
raise the severity back to blocker, as it won't change my current priorities: I'm
currently working on other (and more) "critical" netscape-related stuff for the
branch, which cannot be discussed here.
I'll look at this whenever I'm done, hopefully by this week.
Severity: blocker → critical

Comment 3

16 years ago
I looked at the build on friday and here are my findings:

The osx plugin was present in build 04-23-03, but not in 04-23-08, without any
changes being made in the packaging automation in between.
I noticed that since then, only *empty* directories are created under
dist/viewer/essential files/PrintDialogPDE.plugin, which tells me that the we're
looking at a build problem, not a packaging one.

Once someone fixes the build issue and the .plugin structure is again populated
as part of the build, the packaging will automatically follow and package the
right thing at the right place.

dcone, you should be able to replicate the problem on your system and
investigate from there. Make sure you build optimized. If this works for you
then we'll have to sit down together and see what's different between the build
machines and yours.

reassigning to dcone and cc'ing sdagley and pinkerton who might have an idea
Assignee: jj → dcone

Comment 4

16 years ago
I did a fresh pull and build (optimized).. it pulled the plugin.. and it also 
moved it correclty to the essentials folder.. and when I ran the build.. the 
dialog was extended.  I deleted everything.. I even tested a few times to make 
sure the plugin was pulled.  I dont understand how from one build/package on 
monday to tuesday the plugin came up missing.  And.. the printer plugin in 
gfx/src/mac/printerplugin/printdialogPDE.plugin is all there with my fresh pull.   


Comment 5

16 years ago
After more research, this remains a mistery, but the good news is that our daily
3am clobber builds do include the plugin. Only the 8am 'depend' don't and I
can't really figure out why.
All "manual" attempts to run the portion of the perl script that takes care of
this were successful and I wasn't able to reproduce the problem.

There shouldn't be any difference between clobber and depend cycles since 
'dist' gets emptied with depend builds anyway, so there shouldn't be any
"overwriting" problem.

The culprit seems to be the call to FSpDirectoryCopy in
which fails to copy 'PrintDialogPDE.plugin' properly under certain conditions
and only copies the empty directory structure without any file inside.

I can add a warning to the call to better understand what happens:
   FSpDirectoryCopy (...) or warn (^E);

Asking again for pinkerton and/or sdagley's input on this.

Comment 6

16 years ago
I expect that your problem is that you are not passing an fsspec to a folder...
you are passing one to a file. I changed the build list to copy
":mozilla:gfx:src:mac:printerplugin:" and my depend build copied the
"printerplugin" folder into essential files.

What you are trying to copy however is "PrintDialogePDE.plugin", a package. You
either need to use something that knows how to copy a package, or you will have
to copy the package bits individually... assuming that you can.

Comment 7

16 years ago
> I expect that your problem is that you are not passing an fsspec to a folder...
> you are passing one to a file.

Well, not really. Since we're running the build on OS9, PrintDialogePDE.plugin
is seen as a folder, and FSpDirectoryCopy does its job, just not *every* time. I
will give a try to FSpFileCopy but I doubt it will work.
note that cvs also PrintDialogePDE.plugin as a directory since there are entries
for each file and subdirectory underneath it.

Again, the current script DOES work in our 3am clobber cycle, and I don't get
why it doesn't at 8am, when doing a depend release build.

One solution might be to remove the PkgInfo file from cvs so that the finder
doesn't present PrintDialogePDE.plugin as a "package", which might make
FSpDirectoryCopy happier, then have the perl script create that PkgInfo file
under dist immediately after the call to FSpDirectoryCopy to restore the
"package" structure. A bit uggly, but this could be a viable temporary
workaround, until we build the plugin ourselves.

I'd still like to understand what makes FSpDirectoryCopy sometimes succeed and
sometimes fail.

Comment 8

16 years ago
>Since we're running the build on OS9, PrintDialogePDE.plugin is seen as a folder
But it's not... that's how I came to this conclusion. I went and looked at it in
the Finder (in OS 9) and it is represented as a file of type package.

Comment 9

16 years ago
Brian, it is a folder. You're right when saying that the *Finder* shows it as a
file of type package, but at the file system level, which is what Perl cares
for, it is a directory. Take a look at it from your MacCVS session, you'll see
what I mean.

Any objection with my proposal of cvs removing 'PkgInfo' and have the perl
script create it at build time? I think that's the way to go for the immediate
could macperl perhaps be running out of memory by this late stage of the build
automation? just a wild stab in the dark. try upping macperl's mem partition.

Comment 11

16 years ago
Created attachment 82054 [details] [diff] [review]
Potential fix

Ok JJ, since you didn't like my other idea... :)

I noticed that the call to Activte MacPerl isn't happening until after the copy
is performed. In theory the difference between the clobber build and the depend
build could be that MacPerl might be "activated" before the copy in the
clobber, but not in the depend, build.

This patch causes the package to appear in my Essential Files folder on my
depend build. Can you try this out on your build machine and see if it works
for you?

Comment 12

16 years ago
->JJ.. since he is the package.. guy.. and he can test the solutions.
Assignee: dcone → jj

Comment 13

16 years ago
fyi, I applied bnesse's patch before today's 8am build (not checked in, just
applied locally), and added a " or warn $^E;" to the FSpDirectoryCopy call, but
neither change helped :-(
no warning got reported in the script log, and the .plugin directory got copied
empty to dist once again.

pink: MacPerl is doing lots of things afterwards, namely all the ns build cycle,
so i don't think it's running out of memory at this stage.

another patch i can think of is delete the .plugin dir from dist if it exists
before attempting to copy it.


16 years ago
Keywords: nsbeta1

Comment 14

16 years ago
tfv 1.01 since it needs to be on the branch and the trunk.
Target Milestone: --- → mozilla1.0.1

Comment 15

16 years ago
I think I know why this happens.

When the PrintDialogPDE.plugin folder is initially copied to Essential Files,
the Finder sets its 'package' bit (based, presumably, on the fact that it has
the structure of a package). So the first copy is fine.

In a depend build, we remove the files in 'dist', but leave the directory
structure intact. So this folder is still a package, and that, for some reason,
causes FSpDirectoryCopy() to refuse to copy files into it.

Comment 16

16 years ago
Created attachment 88993 [details] [diff] [review]
Fix: move the old plugin folder to the trash first
Attachment #82054 - Attachment is obsolete: true

Comment 17

16 years ago
Simon's patch works better than the one I had tried, fyi:
   if (-e $essentials_dir . "PrintDialogPDE.plugin") {
      unlink($essentials_dir . "PrintDialogPDE.plugin");

checked in patch in attachment 88993 [details] [diff] [review] on the trunk.
Will checkin on the branch upon verification in upcoming trunk release builds
and confirmation with ADT.

Comment 18

16 years ago
Verified on the trunk. All builds from 6/27 and 6/28 (3am clobber and 8am
depend) include a valid PrintDialogPDE.plugin in the Essential Files.

Unlike what I wrote in my last comment, this is not expected to land on the 1.0

marking fixed.
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.