Closed
Bug 273785
Opened 20 years ago
Closed 20 years ago
plugins not scanned/detected on startup (open-with dialog for PDFs)
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: helmutduregger, Assigned: bzbarsky)
References
Details
(Keywords: helpwanted, regression)
Attachments
(2 files)
6.50 KB,
patch
|
Biesinger
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 1•20 years ago
|
||
Confirming on trunk..
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041208
Firefox/1.0+
Comment 2•20 years ago
|
||
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).
Reporter | ||
Comment 5•20 years ago
|
||
(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.
Updated•20 years ago
|
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+
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 7•20 years ago
|
||
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
Comment 8•20 years ago
|
||
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+
Comment 9•20 years ago
|
||
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+
Comment 10•20 years ago
|
||
(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
Comment 11•20 years ago
|
||
does not work for me with the 2005-01-11 win32 installer build, the list is
still blank.
Comment 12•20 years ago
|
||
see also bug 277921, which affects other apps like Camino.
Comment 13•20 years ago
|
||
Can someone who sees the problem narrow down a regression window? Is it first
broken on 20041203, as bug 277921 reports?
Comment 14•20 years ago
|
||
(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.
Comment 15•20 years ago
|
||
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
Updated•20 years ago
|
Hardware: PC → All
Comment 16•20 years ago
|
||
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).
Comment 17•20 years ago
|
||
We need some traction on this bug. Benjamin?
Comment 18•20 years ago
|
||
I don't know the plugin code, I'm only a "placeholder owner". This may have
something to do with pluginreg.
Keywords: helpwanted
Comment 19•20 years ago
|
||
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
Comment 20•20 years ago
|
||
This is perhaps the same as bug 277921.
Flags: blocking1.8b?
Target Milestone: --- → mozilla1.8beta
Assignee | ||
Comment 21•20 years ago
|
||
When did not scanning for Java on startup land, does anyone know?
Comment 22•20 years ago
|
||
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.
Assignee | ||
Comment 23•20 years ago
|
||
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.
Assignee | ||
Comment 24•20 years ago
|
||
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?
Updated•20 years ago
|
Flags: blocking1.7.6?
Comment 25•20 years ago
|
||
Johnny, can you help here?
Assignee | ||
Comment 26•20 years ago
|
||
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?
Updated•20 years ago
|
Keywords: aviary-landing
Comment 27•20 years ago
|
||
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.
Assignee | ||
Comment 28•20 years ago
|
||
Daniel, it's a problem everywhere if Java is disabled in preferences... See
comment 23 and comment 24.
Comment 29•20 years ago
|
||
No patch in sight, wouldn't hold 1.7.6 for this. a- for 1.7.6
Flags: blocking1.7.6? → blocking1.7.6-
Assignee | ||
Comment 30•20 years ago
|
||
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 31•20 years ago
|
||
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?)
Assignee | ||
Comment 32•20 years ago
|
||
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...
Comment 33•20 years ago
|
||
*** Bug 277921 has been marked as a duplicate of this bug. ***
Comment 34•20 years ago
|
||
bug 277921 (which was resolved as a dupe of this bug) was blocking 1.8b
Updated•20 years ago
|
Flags: blocking1.8b2?
Flags: blocking1.8b?
Flags: blocking1.8b2?
Flags: blocking1.8b2+
Flags: blocking1.8b-
Comment 35•20 years ago
|
||
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 36•20 years ago
|
||
Attachment #173934 -
Flags: superreview?(darin) → superreview+
Comment 37•20 years ago
|
||
is there gonna be a checkin sometime soon?
Assignee | ||
Comment 38•20 years ago
|
||
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 39•20 years ago
|
||
Comment on attachment 174761 [details] [diff] [review]
Followup patch
r+sr=jst
Attachment #174761 -
Flags: superreview+
Attachment #174761 -
Flags: review+
Assignee | ||
Updated•20 years ago
|
Assignee: benjamin → bzbarsky
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
Assignee | ||
Comment 40•20 years ago
|
||
Both patches checked in.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 41•20 years ago
|
||
*** Bug 260100 has been marked as a duplicate of this bug. ***
Comment 42•20 years ago
|
||
> 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?
Comment 43•20 years ago
|
||
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?
Comment 44•20 years ago
|
||
that list somewhere in firefox preferences is unaffected by this patch. that's a
different bug. (a filed one, no doubt)
Assignee | ||
Comment 45•20 years ago
|
||
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).
Comment 46•20 years ago
|
||
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.
Assignee | ||
Comment 47•20 years ago
|
||
Jennifer, see comment 44.
Comment 48•20 years ago
|
||
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.
Assignee | ||
Comment 49•20 years ago
|
||
Bug 282942 filed on the plugin manager thing.
Comment 50•20 years ago
|
||
(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.
Assignee | ||
Comment 51•20 years ago
|
||
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.
Updated•20 years ago
|
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)
Comment 52•20 years ago
|
||
(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.
Comment 53•20 years ago
|
||
(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.
Assignee | ||
Comment 54•20 years ago
|
||
> 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...
Assignee | ||
Comment 55•20 years ago
|
||
*** Bug 282771 has been marked as a duplicate of this bug. ***
Comment 56•20 years ago
|
||
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
Assignee | ||
Comment 57•20 years ago
|
||
> 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.
Assignee | ||
Comment 58•20 years ago
|
||
*** Bug 279763 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Assignee | ||
Comment 59•20 years ago
|
||
*** Bug 284284 has been marked as a duplicate of this bug. ***
Comment 60•20 years ago
|
||
(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.
Comment 61•20 years ago
|
||
*** Bug 281134 has been marked as a duplicate of this bug. ***
Comment 62•20 years ago
|
||
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.
Assignee | ||
Comment 63•20 years ago
|
||
> 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.
Assignee | ||
Comment 65•20 years ago
|
||
*** Bug 287403 has been marked as a duplicate of this bug. ***
Comment 66•20 years ago
|
||
*** Bug 220730 has been marked as a duplicate of this bug. ***
Comment 67•19 years ago
|
||
*** Bug 307008 has been marked as a duplicate of this bug. ***
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•