User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060911 Camino/1.0.3 Build Identifier: Camino/1.0.3 To print to PDF, one usually first open the print window (Command-P) and pushes the PDF button. Then another window opens, for selecting the destination PDF file. Everything works normally, unless, before the printing to pdf (before pushing the PDF button) the print window is first dragged to any new position on the desktop. Reproducible: Always Steps to Reproduce: 1.Command-P 2.Drag the print window somewhere 3.Push the PDF button: it will not work Actual Results: the program does not respond to pushing the PDF button Expected Results: open a window to select the destination PDF file

Curious bug! I see it as well. Can you see if you can reproduce it in the latest Firefox nightly?

WFM on 10.3.9, so I suspect this is an OS bug. Does the problem also happen with other apps using the Print dialogue rather than the sheet (mostly Carbon apps, e.g., GraphicConverter)?

I see this with Camino trunk builds on 10.4.7 PPC. Minefield and BonEcho builds do *not* show this problem, running on the same machine. iCab 3.0 (also uses window rather than sheet) does not show this problem either. Idem dito for Inter Explorer.

philippe, did you check Cocoafox too, or just the Carbonfox Minefield?

(In reply to comment #4) > philippe, did you check Cocoafox too, or just the Carbonfox Minefield? > lemeswitch... Fails in CocoaFox (and CairoCocoaFox). The PDF drop down only works when I don't move the window. All other options and buttons are otherwise fully functional in both Camino and Minefield.

So this is some wacky Cocoa Widget bug? I just remembered that that button is a wacky button-menu thing on 10.4....

If you move it away, and then move it back, it works. I think it's because it's some wacky control. I'll try and figure out what it's subclassing from.

According to F-Script, it is an NSPopUpButton. The cell is PDFPopupButtonCell, which inherits from NSMenuItemCell.

Sorry for the spam, swear I'm done :) It's actually a regular NSPopUpButton. It has some weird values set, but it doesn't look like they are subclassing anything to do custom drawing. Not like they need to when they can just modify Appkit...

Looks like the dropdown menu position "clings" to the original position of the window, moving the print dialog down a few pixels causes the dropdown menu to creep up the PDF button until it is no longer accessible.

Amazingly, the bug title is accurate -- this bug doesn't happen on Mac OS X 10.5 Leopard.

I think it's odd that this easily-work-aroundable, edge-case, 10.4-specific bug is blocking1.9+. There are much better uses of Colin's time over the next few months than figuring out why Tiger is screwing Firefox in a situation that very few users will hit anyway.

Does this happen in any other apps? Have we filed a bug with Apple? We should.

I think I've seen this in Camino as well...

It was filed in Camino. I think Josh meant any other non-Mozilla apps. I can't seem to find one that has the print dialog as a window. Most use sheets.

I'd never looked at the printing code until now, and I notice that it is still written in Carbon. Any technical reason why we're not using the Cocoa printing architecture, or is this just something that is waiting to be done?

Yes there's a reason why it's still written in Carbon. The Cocoa printing APIs are less flexible, and more to the point, quite a bit different from how Mozilla's print API works -- shoehorning the two together seemed like a dangerous and tricky task, and not very high priority because (aside from this minor issue) it works fine for now. I don't want to spend days and days on this bug, but I am going to at least dig into it a little bit. It is very likely that this bug will just have to fall by the wayside. It is really a minor issue, even more so since it works fine on Leopard.

To summarize the blocking1.9- decision... This is a bad side affect of using a carbon printing impl within a cocoa app. There isn't anything we can do about it as far as I can tell without rewriting our printing impl in cocoa. It is fixed in 10.5, which means at least our story gets better as time goes on. Unfortunate though.

So to summarize what I learned about this bug while investigating a few days ago: This is most likely just a weird Cocoa/Carbon integration bug that nobody else has reported because most people use a sheet (by calling PMSessionUseSheets) instead of a modal dialog. If you call that function, though, PMSessionPrintDialog returns immediately (instead of blocking), and the |accepted| outparam has an undefined value, instead of containing the user's choice in that dialog. Instead, to get the user decision on wether or not to print, you provide a callback when you call PMSessionUseSheets, and that gets called when they finally chose an option. However, as far as I can tell, our printing architecture isn't designed to support something asynchronous like that. In 10.5 the print dialog has been re-implemented in Cocoa, and this issue goes away entirely, thankfully. I'm probably not going to work on this bug any time soon, and since it's blocking1.9-, I'm assigning to nobody.

Moving this to have no milestone, since it's definitely not happening for m9 (or really ever?). If this isn't right, chime in. Should we just wontfix this?

This bug is 10.4-only and won't be fixed by the Cocoa print dialog because that won't run on 10.4.

(In reply to comment #23) > This bug is 10.4-only and won't be fixed by the Cocoa print dialog because that > won't run on 10.4. Markus, this bit isn't true any more, right, since the final version of the Cocoa printing code runs on 10.4? (No idea if it fixes this bug or not, though.)

Right.

Can somebody test if this bug still exists on 10.4?

(In reply to Markus Stange from comment #27) > Can somebody test if this bug still exists on 10.4? @Markus Stange Yes, it still exists on 10.4.11. I've been running 10.4 since 2005 and I'm shocked I'm just running across this behavior (running Camino 2.0.7) for the first time. I believe that more than the PDF control is affected; In my limited "testing", I found the following: • The Supplies buttons can be affected, too. Try sliding the print dialog box to the left laterally until the Supplies button overlaps where the PDF button was. Clicking Supplies will activate the PDF button, and clicking outside and to the left of the Cancel button will activate the Supplies button. Moving the Print dialog outside far outside the initial placement will render the PDF and Supplies buttons inoperable. • John Daggett's description is fairly accurate; however if you line up the dialog box just right as I described above, you can activate the Supplies button outside of the bounds of any button. I tried Firefox 3.6.15 (and a few other non-Mozilla applications) on my machine and I haven't found another instance of this type of behavior.

Sorry, I tried Firefox 3.6.13, not 3.6.15 as earlier stated.

OK, but considering that the bug is fixed on 10.5 and that we've dropped 10.4 compatibility, we're probably not going to do anything about it.