Closed Bug 273785 Opened 20 years ago Closed 19 years ago

plugins not scanned/detected on startup (open-with dialog for PDFs)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: helmutduregger, Assigned: bzbarsky)

References

Details

(Keywords: helpwanted, regression)

Attachments

(2 files)

Patch per comment 24
6.50 KB, patch
Biesinger
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
Followup patch
5.01 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The bug was reproduced under "Windows xp pro sp2" and "Linux Redhat 9 gnome",
both on Firefox 1.0 binary installer from mozilla.org.

Firefox does not display plugins in .../Downloads/Plug-Ins (win/linux) after
startup. After typing "about:plugins" it displays them correctly. Also after
accessing a page that uses a plugin like Flash, where Firefox has to check
immediately for the plugin, the plugins' status is updated automatically and the
page displayed correctly.
The problem is significant when opening .pdf files in new tabs. As Firefox
obviously does not check for installed plugins in that special case, it just
displays the "open with" dialog. When typing "about:plugins" before opening a
.pdf in a new tab, it displays it correctly using the acrobat reader plugin.

Reproducible: Always
Steps to Reproduce:
1. install Firefox 1.0 on Win XP Pro SP2, or on Linux Redhat 9 Gnome 2.2.0
2. install various plugins, e.g. Flash, Acroread 5.0.9
3. startup firefox
4. go under /tools/options/downloads/plug-ins (windows),
/edit/preferences/downloads/plug-ins (linux)
5. witness empty plugins text area
6. type "about:plugins" into address field and witness listing of installed plugins
7. repeat step 4
8. witness correct display of installed plugins in text area

Actual Results:  
plugins are only available if detected manually or if forced to be detected by
html code (flash)

Expected Results:  
Firefox should detect all installed plugins on startup so .pdf's can be opened
in new tabs from a link on a page

* bug does occur under standard theme
* running Windows XP Pro Service Pack 2 / Linux Redhat 9 Gnome 2.2.0 on an
Athlon 64, Gnome/Linux/Firefox was NOT compiled by myself
Confirming on trunk..

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041208
Firefox/1.0+
confirming with same OS/build as tablet
->NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
This WFM and Peter(6) in the 1.0 milestone (and in pre-merge trunk builds) but
fails in current trunk builds. Even though the reporter is seeing this in 1.0
I'm going to add the aviary-landing keyword, since for at least 2 people the bug
only became apparent after the merge.

OS: ALL
Keywords: aviary-landing
OS: Linux → All
Summary: plugins are not automatically scanned/detected on startup → plugins not scanned/detected on startup (empty plug-ins dialog in downloads)
I can reproduce the original report with Firefox 1.0 on Win98SE/WinME if I
disable Java (Web Features).
(In reply to comment #4)
> I can reproduce the original report with Firefox 1.0 on Win98SE/WinME if I
> disable Java (Web Features).
Confirmed for WinXP and Linux. Had java initially disabled.
Summary: plugins not scanned/detected on startup (empty plug-ins dialog in downloads) → plugins not scanned/detected on startup (empty plug-ins dialog in downloads, open-with dialog for PDFs)
I had java installed already and it did it for me.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041221
Firefox/1.0+
Flags: blocking-aviary1.1?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050111
Firefox/1.0+

WFM

The problem appears to have vanished, I'll check on another computer tomorrow
Still does it for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a6) Gecko/20050111 Firefox/1.0+
I can still reproduce as well.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050110
Firefox/1.0+
(In reply to comment #7)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050111
> Firefox/1.0+
> 
> WFM
> 
> The problem appears to have vanished, I'll check on another computer tomorrow

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050112
Firefox/1.0+

WFM , on a different machine
does not work for me with the 2005-01-11 win32 installer build, the list is
still blank.
see also bug 277921, which affects other apps like Camino.
Can someone who sees the problem narrow down a regression window? Is it first
broken on 20041203, as bug 277921 reports?
(In reply to comment #13)
> Can someone who sees the problem narrow down a regression window? Is it first
> broken on 20041203, as bug 277921 reports?

I can confirm that it regressed between 01-Dec-2004 and 04-Dec-2004.
Unfortunately, I can't find a 02-Dec-2004 build that works and I can't find a
03-Dec-2004 build at all.  But yes, 01-Dec-2004 worked fine and 04-Dec-2004
exhibits this problem.
Don't think it's going to be easy to get a better regression window than that -
all the aviary branch stuff landed in two lumps and the builds between the two
lumps and immediately following were pretty broken.
Severity: normal → major
Keywords: regression
Hardware: PC → All
I hope this is the correct place to put this information, as I think it is the
same bug, but if it needs a new log please let know and I will create one.

The problem appears to be worse than originally described, because not only are
the plugins not scanned / detected on launch, but the enabled / disabled setting
on plugins appears to be getting ignored and all plugins are treated as enabled.

<REPRODUCTION STEPS> - problem occurs with new and existing profiles
If after doing about:plugins you go the plugin options screen, you will notice
all plugins are enabled (I have most disabled by default using my BRANCH build).

Disable a plugin, then select OK.
Return to the plugins screen - the plugin is still enabled (and fully functional).

If I use my existing BRANCH profile, the plugins correctly show as disabled and
do not work.
However, If I start the TRUNK build, the plugins work immediately (and if I do
about:plugins, show as enabled).
If I then go back to my BRANCH build, the plugins are still showing as disabled
and do not function (which is as expected).
We need some traction on this bug. Benjamin?
I don't know the plugin code, I'm only a "placeholder owner". This may have
something to do with pluginreg.
Keywords: helpwanted
Depends on: 242321
This had better be moved to Core:Plugin. After that, I'm gonna nominate as a
1.8b blocker.
Component: Startup and Profile System → Plug-ins
Product: Firefox → Core
Version: unspecified → Trunk
This is perhaps the same as bug 277921.
Flags: blocking1.8b?
Target Milestone: --- → mozilla1.8beta
When did not scanning for Java on startup land, does anyone know?
Blocks: 279763
just after aviary stuff landed on trunk Boris (see comment 3).
The machines were in flames and builds far from stable so not many people
volunteered to try them.
I don't see anything in comment 3 about Java...

The bug I was thinking was bug 128366.  It landed on Dec 2, looks like, and I
bet it cased this bug for a lot of people if plugin scanning is broken in general.
So the problem is that nsDSUriContentListener assumes that the
Gecko-Content-Viewers category has all the entries it should.  At startup, it
does not.  See the call to ReloadPlugins() in nsDocShell::NewContentViewerObj to
see where the category is properly populated (in the end via
nsPluginTag::RegisterWithCategoryManager).

So as a quick hack, we could move the "reload plugins" code out of docshell and
into the DSURIContentListener, I guess...  This will, of course, break all
embeddors that are using the Gecko-Content-Viewers thing in their
nsIURIContentListener implemetations (that would be all of them).  But they're
already broken wrt plugins at the moment, unless they load them manually
somewhere else...

Note that the patch for bug 128366 is indeed what triggered this for people who
have Java enabled . Before that patch, having Java enabled tried to look for the
Java plugin at startup, which loaded the plugin contracts into the category manager.

biesi, darin, thoughts?
Flags: blocking1.7.6?
Johnny, can you help here?
Talked to biesi a bit.. unless we hack every single Gecko-Content-Viewers user,
the only way to get this "right" is to have some sort of core function that will
check the category, try to load plugins, then recheck the category as needed and
switch over to using that instead of reading the category directly....  That
would help embeddors too.

For a short-term fix, we could hack things to LoadPlugins() on startup, or we
could do what I suggested in comment 24.  Any preferences?
Why is this nominated for 1.7.6? I don't see any comments that indicate this is
a problem on the 1.7 branch.
Daniel, it's a problem everywhere if Java is disabled in preferences... See
comment 23 and comment 24.
No patch in sight, wouldn't hold 1.7.6 for this. a- for 1.7.6
Flags: blocking1.7.6? → blocking1.7.6-
Attached patch Patch per comment 24 — — Splinter Review 
Er... I've had a patch per my comments sitting in my tree since I made the
comments....

I guess the only way I'll get feedback from people on the approach is if I make
them review it, eh?
Attachment #173934 - Flags: superreview?(darin)
Attachment #173934 - Flags: review?(cbiesinger)
Comment on attachment 173934 [details] [diff] [review]
Patch per comment 24

hm... I guess this works for this case, but it does not fix other users of this
category in the tree...

it also does not help embeddors, I think - should plugins be reloaded around
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDSURIContentListener.cp
p#156 too? (at least if that call returned false?)
Possibly, yes.  That may actually address the current embedding issues....

I'm not going to have a chance to look into that until sometime next week,
though.  So if someone else has time...
Blocks: 277921
No longer blocks: 277921
*** Bug 277921 has been marked as a duplicate of this bug. ***
bug 277921 (which was resolved as a dupe of this bug) was blocking 1.8b
Flags: blocking1.8b2?
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking1.8b-
Comment on attachment 173934 [details] [diff] [review]
Patch per comment 24

ok, this will fix the problem, so r=biesi

but it still won't help embeddors...
Attachment #173934 - Flags: review?(cbiesinger) → review+
Comment on attachment 173934 [details] [diff] [review]
Patch per comment 24

sr=darin
Attachment #173934 - Flags: superreview?(darin) → superreview+
is there gonna be a checkin sometime soon?
Attached patch Followup patch — — Splinter Review 
This is to be applied on top of the other patch... I ran into a case when the
plugin manager claims there are new plugins when there aren't any, which put
this code into an infinite loop, of course.
Comment on attachment 174761 [details] [diff] [review]
Followup patch

r+sr=jst
Attachment #174761 - Flags: superreview+
Attachment #174761 - Flags: review+
Assignee: benjamin → bzbarsky
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
Both patches checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 260100 has been marked as a duplicate of this bug. ***
> I ran into a case when the
> plugin manager claims there are new plugins when there aren't any, which put
> this code into an infinite loop, of course.

sounds like a bug in the plugin manager; can you file it?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050220
Firefox/1.0+ with an old profile.
Is this bug fixed for everyone? I am still seeing an empty plug-ins list until I
do about:plugins - or is this only fixed for new profiles created since the
patch landed?
that list somewhere in firefox preferences is unaffected by this patch. that's a
different bug. (a filed one, no doubt)
This patch addresses what happens when you actually load a full-page plugin. 
With this patch, that works.

As biesi said, the preferences thing is a separate bug (and needs to be fixed in
preferences by making sure to call reloadPlugins on the plugin manager before
trying to get lists of plugins).
I installed the Feb 19 2005 build and found the Plugins box in the ptions
download box to be unpopulated until typing about:config. Just installed
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050220
Firefox/1.0+ and looks to see if it is fixed on this build. Finds it still does
not scan all the plugins. These are two shots one, before and one after

http://images5.theimagehosting.com/aboutplugins.jpg
http://images5.theimagehosting.com/aboutpluginsp.jpg

The first is a before shot, the second is after typing about:plugins

The issue arose when trying to view a Shockwave file and it asked for the plugin
to view it with. Also with Shockwave Director 10.1 for FF. Seems that is still
does not work even with it installed. I don't think it's fixed yet.
Jennifer, see comment 44.
Camino now correctly handles loading plugin related content trough a link using
2005021908 (v0.8+) trunk build. Thank for fixing this guys. 

I filed bug 277921 for our issues.
Bug 282942 filed on the plugin manager thing.
(In reply to comment #44)
> that list somewhere in firefox preferences is unaffected by this patch. that's a
> different bug. (a filed one, no doubt)

Not too sure. This one is a problem since EACH time I have to use about:plugins
to get them to show, it does not remember it at all.


Not too sure about what?

Note that the summary of this bug mentions two separate issues.  The second one
(the one that's a bug in Gecko) is fixed by this patch.  The first one is a bug
in the Firefox UI and needs to be fixed there.  If there is no bug for it
already, a bug needs to be filed.
Summary: plugins not scanned/detected on startup (empty plug-ins dialog in downloads, open-with dialog for PDFs) → plugins not scanned/detected on startup (open-with dialog for PDFs)
(In reply to comment #51)
> Not too sure about what?
> 
> Note that the summary of this bug mentions two separate issues.  The second one
> (the one that's a bug in Gecko) is fixed by this patch.  The first one is a bug
> in the Firefox UI and needs to be fixed there.  If there is no bug for it
> already, a bug needs to be filed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050220
Firefox/1.0+

Ok this is how this works for me. First how do I go about posting a new bug? I
have threee screen shots of before, did and after of the about:plugins. In this
order.

http://images5.theimagehosting.com/aboutplugins.jpg
No Plugins
http://images5.theimagehosting.com/aboutpluginss.jpg
Typed about:plugins
http://images5.theimagehosting.com/aboutpluginsp.jpg
Populated

This all happens each and every time. I have tried to edit the config but so far
has not found the correct entry. To date, I thought originally the Shockwave and
Flash players just needed to be reinstalled. So upon doing that, it repopulateds
the Options Box. Then the next day restarted Firefox and the Plugins were gone.
On a note with Adobe Reader, suggests updating it to 7.0 for better PDF
handling. so far even when the plugins are not showing when I open any document
that is a PDF file it launches Adobe 7.0 with no problem. Currently I think this
is a serious issue and needs a major address. To have to type about:plugins upon
loading Firefox can be cumbersome when looking from an e-mail to a link that
uses Flash or Shockwave.
(In reply to comment #52)

> Ok this is how this works for me. First how do I go about posting a new bug? I
> have threee screen shots of before, did and after of the about:plugins. In this
> order.

We all know what you've been saying and don't need to see your screenshots. I
filed a new bug for you (bug 283043). Please, let this bug rest in peace.

> Currently I think this
> is a serious issue and needs a major address. To have to type about:plugins upon
> loading Firefox can be cumbersome when looking from an e-mail to a link that
> uses Flash or Shockwave.

You do not have to type 'about:plugins'. (before this bug was fixed, you had
to.) Just go to any page that needs a plugin and it'll work without any
intervention of yours.  The plugin list not being automatically populated before
visiting any page that needs a plug-in is not a serious bug although it's a
minor nuisance.



> First how do I go about posting a new bug?

Most simply, you click the "Enter New Bug" link at the top of this bug page.  Or
you do a Google search on "mozilla bug" and follow the first hit -- that puts
you on a page that has a huge "Report A Bug" link.  You could also search on
"report mozilla bug"; that would give you the same hit...
*** Bug 282771 has been marked as a duplicate of this bug. ***
Probably a part of the bug still exists even in Mozilla/5.0 (Windows; U; Windows
NT 5.0; en-US; rv:1.8b) Gecko/20050217.
Please have a look to
https://bugzilla.mozilla.org/show_bug.cgi?id=279763
> Probably a part of the bug still exists even in Mozilla/5.0 (Windows; U;
> Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217.

That build is from the day BEFORE the patch for this bug was checked in.
*** Bug 279763 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
*** Bug 284284 has been marked as a duplicate of this bug. ***
(In reply to comment #57)
> > Probably a part of the bug still exists even in Mozilla/5.0 (Windows; U;
> > Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217.
> 
> That build is from the day BEFORE the patch for this bug was checked in.
All right, works for me now with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b2) Gecko/20050301. I believed that It had been fixed in the release of 1.8b.

*** Bug 281134 has been marked as a duplicate of this bug. ***
This Bug has not been fixed in Mozilla 1.8b.
It is exactly the same as in Firefox 1.0 and 1.01.
With disabled java plugins do not work, 
after call "about:plugins" all plugins work fine.

At my Satus i can not reopen this bug,
but there is no release which does not show this bug.
> This Bug has not been fixed in Mozilla 1.8b.

Of course.  This bug was fixed AFTER 1.8b1.  See comment 57, and generally do
everyone a favor and read bugs before commenting.
verified fixed with Gecko/20050305
Status: RESOLVED → VERIFIED
*** Bug 287403 has been marked as a duplicate of this bug. ***
*** Bug 220730 has been marked as a duplicate of this bug. ***
*** Bug 307008 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: