Closed Bug 409226 Opened 18 years ago Closed 9 years ago

Plugins not rendered behind dialog box after Cocoa widgets

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: vlad.alexander, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2 We are a plug-in vendor and we make a plug-in for Firefox. In FF3b2, when our plugin displays a dialog box or even if there is a JavaScript dialog box on the page, the plugin disappears for the duration of the dialog box. Here is a screen shot of our plugin without a dialog box: http://misc.xstandard.com/mozilla/rendered.gif Pressing the image button on the toolbar will bring up a dialog box. The plug-in will disappear as shown in this screen shot: http://misc.xstandard.com/mozilla/not-rendered.gif Our plugin was being rendered correctly when there was a dialog box on the page in FF2. Reproducible: Always Steps to Reproduce: 1. Download and install our plug-in from: http://xstandard.com/download/x-lite.dmg (when prompted to reboot, ignore and just close the dialog box and re-start the browser) 2. Go to this test page: http://xstandard.com/test.asp 3. Press the Image button on the toolbar. Actual Results: A dialog box will display and the plug-in will disappear. Expected Results: A dialog box should display and the plug-in should continue to be rendered behind the dialog box.
Summary: Plugins not rendered correctly behind dialog box → Plugins not rendered correctly behind dialog box in FF3b2
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
I found the build where this got broken. The last FF3 build where the rendering behavior is correct: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-28-08-trunk/ The next build that I could find where it's broken: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-29-06-trunk/
I would like to request that this bug be marked as blocking1.9. This is a regression and comment #2 specifies the nightly build where this bug first occurred. This is a serious bug for us because in some circumstances, users need to see the text in the plug-in when a dialog box is open. Our spell checker dialog box is one such example. Thank you in advance.
Keywords: regression
Flags: blocking1.9?
Do we have any evidence that this is not a bug in the xstandard plugin? Can you reproduce this with Flash or anything else?
I cannot rule out that it's an XStandard bug but it's unlikely. This worked in FF2 and in FF3 dev builds up to build 2006-09-29. If you let me know of another plug-in that generates a modal dialog box, I will invest the time to reproduce this with another plug-in.
Vlad, Can you please find another plug-in that generates a modal dialog box or even better attach a reduce test case that does exactly that? If we can show that this indeed isn't a bug in XStandard and is indeed a regression, I'll reconsider blocking. Re-nom this once we have a reduced test case, please.
Flags: blocking1.9? → blocking1.9-
I reproduced the problem with QuickTime. Here is a screen shot: http://misc.xstandard.com/mozilla/quicktime.gif Steps to reproduce the problem are: 1. Go to: http://www.apple.com/trailers/wb/getsmart/trailer3/small.html 2. Pause the movie playing in the QuickTime plug-in. 3. Bring up the context menu over the plug-in and select "About QuickTime Plug-in...". Damon, please consider fixing this in FF3. XStandard uses modal dialog boxes for most features. This is an important issue for us and our users.
Given that ... 1. This bug is a regression. 2. We found the exact FF3 build where this broke. 3. This is an important issue for us as a plug-in vendor. ... please, can you flag this bug as blocking1.9 so that it can be fixed before FF3 is released? We will help as much as we can to test the fix.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I may have found the cause. The plug-in generates a modal dialog box. But FF on OS X behaves as through it's a modeless dialog box.
(In reply to comment #7) > I reproduced the problem with QuickTime. Here is a screen shot: > > http://misc.xstandard.com/mozilla/quicktime.gif > > Steps to reproduce the problem are: > > 1. Go to: > http://www.apple.com/trailers/wb/getsmart/trailer3/small.html > > 2. Pause the movie playing in the QuickTime plug-in. > > 3. Bring up the context menu over the plug-in and select "About QuickTime > Plug-in...". > > Damon, please consider fixing this in FF3. XStandard uses modal dialog boxes > for most features. This is an important issue for us and our users. > I just tried this testcase on safari. The about dialog comes up as modal. It covers the plugin (except for 10-30 pixels on the right hand side) and I cannot move it to uncover the plug-in. So in general the plug-in is not usable while the modal dialog is visibile. What is it that you wanted this testcase to demonstrate?
(In reply to comment #2) > I found the build where this got broken. > > The last FF3 build where the rendering behavior is correct: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-28-08-trunk/ > > The next build that I could find where it's broken: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-29-06-trunk/ > I'm guessing bug 326469 which is cocoa widgets josh?
The QuickTime test-case is just a means to demonstrate that the problem is not limited to our plug-in, XStandard. Please try this with XStandard. You can download the plug-in from: http://temp.xstandard.com/dev/27/XStandard.plugin.zip Unzip this to /Library/Internet Plug-ins Then go to: http://xstandard.com/test.asp Press the Image button on the plug-in's toolbar. A dialog box comes up, the plug-in behind it disappears. The dialog box should be modal but it's not. You can compare this behavior with FF2 and Safari. FYI, our plug-in written using Carbon.
Thank you so much Mike for looking into this. I just want to provide more info on the modal dialog behavior. Here is a screen shot of how a modal dialog box from a plug-in can render behind FF3: http://misc.xstandard.com/mozilla/dialog-box.gif
(In reply to comment #10) > I just tried this testcase on safari. The about dialog comes up as modal. It > covers the plugin (except for 10-30 pixels on the right hand side) and I cannot > move it to uncover the plug-in. So in general the plug-in is not usable while > the modal dialog is visibile. In that particular instance, yes, but I see Vlad's point -- plugin content behind a dialog should still render, even if you can't directly interact with it while the dialog is up. In Vlad's case, there is information presented in the plugin that might be necessary to see while interacting with the dialog. In theory, this could easily happen with Flash or Director content, too.
Summary: Plugins not rendered correctly behind dialog box in FF3b2 → Plugins not rendered behind dialog box after Cocoa widgets
Hrm, I do wonder if maybe this is specific to plugins using QuickDraw, however. (Does QuickTime use Quartz for its drawing yet?)
Hardware: Macintosh → All
Since I found the exact build where this got broken, see Comment #2, would it be possible to ask the developer who checked in changes to OS X for this build to review this bug report? Maybe he/she can easily spot the cause the of the problem?
(In reply to comment #16) > Since I found the exact build where this got broken, see Comment #2, would it > be possible to ask the developer who checked in changes to OS X for this build > to review this bug report? In order to do that, you'd have to figure out precisely what checkin broke it. I *think* this should be a fairly accurate list of the possibilities: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-28+07%3A00&maxdate=2006-09-29+07%3A00&cvsroot=%2Fcvsroot I don't see anything in there that jumps out at me right away, but maybe someone else does.
Ugh. Never mind. Yeah, Cocoa widgets is in there, and that seems mighty likely, as Schrep pointed out in comment 11. I don't think "easily spotting the cause of the problem" is going to happen, though, because turning on Cocoa widgets was a relatively HUGE change. If you're really curious, you might hunt down a regression window using Camino, which had Cocoa widgets turned on from the beginning. If you can't find any builds of Camino in which your plugin works, I'd guess the bug is in your code's assumptions about how widgets work.
Chris, thank you for the info about Camino. The last Camino build where the rendering behavior is correct: http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2005/04/2005-04-14-08/ The next build that I could find where it's broken: http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2005/04/2005-04-16-08/
I think I just ran into this tonight...with Manfred Schubert's PDF Browser Plugin in Camino trunk. Triggering a save dialog on a window with a PDF displayed in it via the plugin causes the entire plugin to go blank. Dismissing the save dialog restores the plugin content. Haven't tried in Minefield yet, though.
(In reply to comment #21) > Triggering a save dialog on a window with a PDF > displayed in it via the plugin By which I mean "click the Save button in the PDF Browser Plugin's toolbar"; hitting Cmd-S doesn't cause it. That's consistent with the behaviour Vlad reports; only modal dialogs generated by the plugin itself exhibit the problem.
Now that FF3 has shipped, can this bug be looked at for an upcoming point release? Thank you in advance!
(In reply to comment #20) > Well, nothing in there is jumping out at me either, but here's the regression > window if someone else wants to take a stab at it: > > http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-14&maxdate=2005-04-16+09%3A00&cvsroot=%2Fcvsroot > > Maybe bug 289842? Either the XPCOM event queue or layout/view changes seem more likely, although nothing in that range really seems super-likely based on descriptions: bug 289792, bug 287616, bug 284389
Blocks: 326469
Hi, I have tested this issue on Mac OS X 10.10 with FF Nightly 48.0a1 (2016-04-06) I can't reproduce it because the links from Description are not working. If you can reproduce it with the newest version of Firefox please add STR.
Flags: needinfo?(vlad.alexander)
i, Marking this as Resolved: Incomplete due to the lack of response from the reporter. Reporter, please feel free to reopen it if you are still having this issue on the latest Firefox version.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(vlad.alexander)
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.