From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (Win95; U) BuildID: 2000110604 When I load a PDF document and view it with the Acrobat plugin inside Mozilla, the Mozilla window title is not updated, so it continues to display the title of the previous page viewed. Reproducible: Always Steps to Reproduce: 0. Make sure you have the Acrobat plugin installed. 1. Go to an arbitrary web page - say http://home.netscape.com Note the window title (e.g., "Netscape.com") in the blue title bar at the top of thw browser window. 2. Now go directly to a PDF document in the same window - http://web.mit.edu/norstadt/Public/election.pdf is a good example. The PDF document will appear in the browser window (inside the Acrobat plugin interface), and note the Mozilla title bar. It remains unchanged, showing the title of the previous document. 3. Actual Results: The title bar continues to display the title of the previous document. Expected Results: The title bar should display the title of the current document (What should it be? In NS 4.7x it is empty; I think it should be the URL of the document.) Not sure if this impacts the document.title property or is just manifested in the browser window title bar.

Same problem build 2000110904 Win98

not sure if this belongs to plugins or apps. over to plugins first.

updating summary - affects all plugins. Happening on NT. Will check Mac later.

Moving to m1.0 and reassigning to peterl.

Confirming 2k. I can't believe we do not update the title bar for full-page plugins. Should be easy task to fix.

This needs to be done with embedding in mind. Jud, do you know how to do this?

As long as we're consistent about how we update the page title between regular content, and plugin content (sounds like we're not), embedding will be fine.

r=valeski

sr=waterson

chofmann approved on behalf of drivers@mozilla.org for inclusion in 0.9. /be

Patch checked in. Marking FIXED. /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v <-- nsDocShell.cpp new revision: 1.269; previous revision: 1.268

This is not fixed yet. Using nsnull gives too many assertions in debug builds. Safer to use " ".

This is a much better patch. It prevents mTitle from being null and prevents the asserts.

nominating nsbeta1 based on peterl's comments to my pdt bug list . sounds like peterl has a fix in hand.

Took a closer look at this. Setting the title to null or even blank in nsDocShell is wrong because it's too general. There are too many cases that null or blank causes ASSERTS which could possibly cause havok down the road. Since this only effects full-page plugins to my knowledge, a simple QI of the content viewer should reveal if it's implementing a plugin interface. However, full-page plugins don't have any interface. The class nsPluginViewerImpl doesn't actually implement nsIPluginViewer because it doesn't exsist! Andrei would it be okay for me to create an nsIPluginViewer and have nsPluginViewerImpl implement it? Then, Jud/Adam could I do a QI on it in nsDocShell and then and only then set the title to null? Perhaps there is an easier way, but if nsIPluginViewer were IDL-ized then I guess it could be usefull for other things. Not quite sure about other benefits of IDL.

That's a good idea. Maybe nsPIPluginViewer?

Looking at the class again, nsPluginViewer.cpp, I don't see any reason to use IDL as there doesn't look like any methods I want to make public (yet). Could someone correct me if I'm wrong?

yea, it's best to avoid creating an interface simply for "type" identification so you can special case behavior. Should full page plugins have *some* window title? If so, I could see creating a nsIPluginViewer.idl that had a readonly title attribute on it. So in the docshell you could ask for nsIPluginViewer, and call GetTitle() on it.

That sounds like a nice feature since it appears that 4.x reverts to saying "Netscape" and IE makes the title of the page the URL of the PDF. I guess the quickest way to fix this would be to do what IE does. If there is an url, then use that for the title in the docshell. Plugins will have an url and my guess is that others that ASSERT on null titles won't have an href. But there would probably be other things I could think of that a full-page plugin inteface would be good for. Some may overlap code already in nsObjectFrame.cpp

Moving to m0.9.2

->[no eta]

The following patch creates a new public interface, nsIPluginViewer and has has PluginViewerImpl implement it. Then, in nsDocShell, when we create the content viewer, I check if it's a nsIPluginViewer and clear the title bar. So much work just to clear the title bar for full-page plugins, but I'm seeking reviews (or other ideas). Oh, as a side effect, it also has a one-line fix for bug 80105.

It is quite an amount of work but I think it is pretty straightforward and should not introduce any implications. Also, having an interface for a plugin viewer is not a bad idea in my opinion. r=av Just a minor thing not affecting r= , is it going to be plain blank? Why not to write something there like 'Netscape 6' or whatever the application name can be.

It won't be blank, it'll be the "default" (which in the cas e of Mozilla includes the name and buildID. The reason for all this work is because I couldn't set all content viewers to "default" in the docshell because I got a ton of ASSERTs and I felt I may have introduced regressions. Adding this, pretty much dummy interface seemed like least amount of risk and with our macros, it's not too much coding.

Peter, I've just checked in NS_RELEASE --> NS_IF_RELEASE in nsPluginViewer, so you may remove it from your patch.

Looks good. sr=attinasi

a=chofmann

Patch checked in, marking FIXED.

just tracking

verif working on win /mac 0624