Closed Bug 106411 Opened 23 years ago Closed 23 years ago

"Starting plugin for type" keeps showing in status bar

Categories

(Core Graveyard :: Plug-ins, defect, P3)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: serhunt)

References

(
URL
)

Details

(Keywords: embed, topembed-, Whiteboard: [ADT2 RTM])

Attachments

(3 files)

patch v.1
(deleted), patch
Details | Diff | Splinter Review
branch patch v.1
(deleted), patch
srgchrpv
: review+
beard
: superreview+
jesup
: approval+
Details | Diff | Splinter Review
trunk patch v.2
(deleted), patch
srgchrpv
: review+
Details | Diff | Splinter Review 
If you go to:
http://yonkis.ya.com/imagenes5/guerra/talibamm.htm
the messages "Starting plugin for type bla bla bla" keeps showing in the status
bar. Well it cant be starting all that time.

Perhaps after the plugin har started the status text should change to:
"Plugin succesfully started for bla bla bla
This is probably related to bug 106253. Making dependency.
Depends on: 106253
*** Bug 119058 has been marked as a duplicate of this bug. ***
test url : http://www.flash.com
OS: Windows 2000 → All
Hardware: PC → All
It does it for me, too (build 2002011103).  It's very annoying.  Any page that
has a Shockwave plugin (and probably other types of plugin as well) takes over
the status line and doesn't give it back until you go to a different page.  This
means that the usual mouseovers to see where links go don't work.  In fact, even
switching to different tabs (when you have several pages open in different tabs)
doesn't give back the status line.
Keywords: mozilla1.0
*** Bug 120479 has been marked as a duplicate of this bug. ***
statusbar also gets stuck when a java applet starts (linux cvs)
*** Bug 120576 has been marked as a duplicate of this bug. ***
*** Bug 120879 has been marked as a duplicate of this bug. ***
could this be related to bug 117986 ?
is bug 104532 related too?
nsbeta1+ per ADT triage.  Note that bug 106253 is plussed also.
Keywords: nsbeta1 → nsbeta1+
Changing TM 1.0 because this has been accpeted as nsbeta1+.
Target Milestone: --- → mozilla1.0
adding adt3 to status whiteboard as per discussion with beppe.  assign priority
p3 since this is really just a nuisance.
Priority: -- → P3
Whiteboard: [ADT3]
Nomianting for topembed because of bug 106253.
Keywords: topembed
minusing to topembed- as per edt meeting since this bug does not appear in one
of the embedding customers at this point.  We will reconsider nominating this
bug if this bug appears in an embedding customer.
Keywords: topembed → topembed-
Attached patch patch v.1 (deleted) — — Splinter Review 
This patch shows three types of messages in the status bar: Starting plugin,
Plugin started and Cannot start plugin, depending on the plugin start status.
Note that Plugin started means that plugin is loaded and started to do its job.
Which job may include loading data to play such as in the original test case.
In general, we cannot control status of what is happening with the plugin
itself -- this is plugin job to reflect, say, status of the data being
downloaded in the browser status bar.

Please review.
can we set a timer of sorts and allow a message to be displayed for x period of 
time and then just silently remove it? Or in the case of a failed case, display 
an error message -- or something along those lines.
I no longer see the "Starting Plugin for type" message at all with this patch. I
only see the "plug-in started" message and it still remains on the status bar
instead of "Done"

Is there some better way to set the status bar message so it's not "sticky"?
Maybe using Javascript?
I am adding hewitt and blake to the cc list, maybe they can help us out here.
Peter, you don't see 'Starting plugin' message because it takes no time to start
it. With this patch the behaviour is exactly the same as with Java applets.
'Applet started' stays in the status bar when it is all finished.
Havn't we also passed the localization freeze? What good is the "starting...."
message if you can't see it?
True. I am not sure why we had it added in the first place. Check in comment
does not reveal the bug number associated with this change. At some point I even
thought of just removing the 'Starting...' message, and still not sure this is
not our best solution under current circumstances.

But, in theory, starting plugin may take time. Plugin may do some time consuming
stuff during NPP_New call.
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
Upping to ADT2 per meeting
Keywords: nsbeta1-, topembed- → nsbeta1+, topembed+
Whiteboard: [ADT3] → [ADT2]
Attached patch branch patch v.1 (deleted) — — Splinter Review 
This patch just simply removes the code causing 'Starting plugin...' message as
we decided to do at the latest plugin group meeting, given we already passed
the localization freeze and adding new strings will not be acceptable.

Please review for a check in to the branch.
Attached patch trunk patch v.2 (deleted) — — Splinter Review 
This patch is capable of displaying three types of messages: Starting plugin,
Plugin started for type application/something and Cannot start plugin. If
everything goes as planned it all will end up with the 'Started plugin...'
message making it en par with 'Applet started' message we see after loading
pages with Java applets.

The patch is a little more than just fixing this particular bug.
  - it moves plugin related strings form downloadProgress.properties and
region.properties to plugins.properties as a clean up effort. Please yell on me
if this is a wrong thing to do, I'll get it back immediately
  - replaced 'Plugin Downloader Plugin' wording with 'Default Plug-in' just to
make it look less stupid to my taste
  - replaced 'plugin' with 'plug-in' in GUI messages to make it up to the
current English grammar
  - changed check box label wording to more compact form in No Default Plugin
dialog
  - removed some exessive aesthetics (to my taste again) from the about:plugins
page
Please review.
Comment on attachment 81019 [details] [diff] [review]
branch patch v.1

I like this patch a lot:)
why do we need these messages at all?
r=serge
Attachment #81019 - Flags: review+
Comment on attachment 81048 [details] [diff] [review]
trunk patch v.2

the patch itself looks fine to me, r=serge
but anyway 'Started plugin...' message will confuse the users, and
I personally vote for removing these messages code from the trunk too,
to me it would be more useful to show something like plugins finder message
along with
small clickable icon in case there is unknown plugin on the page, which is the
feature request though.
Attachment #81048 - Flags: review+
Shrir, please test the status bar messages.
sure, I will but once this is checked in.
Keywords: topembed+ → embed, topembed-
Comment on attachment 81019 [details] [diff] [review]
branch patch v.1

sr=beard, ah removing code feels good.
Attachment #81019 - Flags: superreview+
Comment on attachment 81048 [details] [diff] [review]
trunk patch v.2

I would prefer we just remove the code from the trunk, just as we did in the
branch.
so far 2 votes for removing this from the trunk, any one else?
I vote for removing from trunk, too.
Me.
count me in on that vote too
Cool, looks like I have my arms untied :)
On the trunk now. Nominating for the branch.
Keywords: adt1.0.0
Whiteboard: [ADT2] → [ADT2][fixed on trunk]
Does not occur in mfcembed 1.0.0 (tested in 4/19 build) or proprietary embed
client, thus the minused topembed kw.  
Comment on attachment 81019 [details] [diff] [review]
branch patch v.1

a=rjesup@wgate.com for branch checkin
Attachment #81019 - Flags: approval+
It is on both the trunk and the branch now. Marking fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
Whiteboard: [ADT2][fixed on trunk] → [ADT2]
removing fixed1.0.0 keyword because I've been forced to back it out from the
branch, see bug 141518. Should I reopen it?

Please approve for check it in back.
Keywords: fixed1.0.0
Changing to adt2 rtm/adt1.0.0-.
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [ADT2] → [ADT2 RTM]
Blocks: 143047
looks fine on trunk 0509. verified it with a few other tests as well. 
Adding adt1.0.0+ for 1.0 branch checkin approval.  Please get drivers approval
again since it's been more than 3 days since a=drivers was given.
Keywords: adt1.0.0- → adt1.0.0+
wfm on nt4.0 using trunk build 2002051408 
This is fixed using win XP trunk build 2002051408
I DO see the behavior in these:
1.0 RC1        Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
1.0 RC2        Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
1.0 RC2        Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020513
Debian/1.0rc2-1
I DO NOT see the behavior in this one:
Mozilla 1.0.0+ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020511 
which is a Debian CVS snapshot package.
But I sure like the video though ;-)
What you see exactly reflects the situation: the fix is on the trunk but is not
on the branch yet.
a=rjesup@wgate.com re-approval for branch checkin
This is on M1.0 branch now.
Keywords: fixed1.0.0
using branch bits from 20020517 on win98, verified the status bar no longer
displays the string.

also tested:
http://mozilla.org/quality/smoketests/   3(o). Browser Plugins (optional)
-- test cases pass

http://mozilla.org/quality/browser/front-end/testcases/plugins/
-- test cases pass

http://acroeng.adobe.com/BrowserTestSuite/
-- test cases pass

Also tested
Acrobat
WinAmp
QuickTime
Flash
Shockwave
MediaPlayer
RealPlayer8


verified a while ago(trunk/brnch both). updating now.
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
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: