Kathleen :Brade Reporter
	Description • 26 years ago

Sometimes when I'm surfing, I stumble across a site that wants to start up Java.
On some sites I'm willing to start up Java but on other sites (depending on what
I'm surfing) I don't want to pay the price of Java startup.

My suggestion is to (hidden preference?) prompt the user whether to startup Java
or not.  If the user says OK (start Java), proceed as normal.  If the user says
"no" (don't start Java) then finish loading the page without Java (as if the user
pressed the Stop button) or take the user back to the previous page.  (The UE
group may have an opinion on what happens when the user chooses not to start
Java; you may chose to do something else...I leave it up to you.)

	Warren Harris
	Comment 1 • 26 years ago

I guess this could get added to OJI -- or to plugins in general. Assigning to
Alex.

	Paul MacQuiddy
	Comment 2 • 26 years ago

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

	rubydoo123
	Comment 3 • 26 years ago

setting Greg as QA contact

	sujay
	Comment 4 • 26 years ago

claudius,re-assigning some of Greg's open bugs to you.

	Alex Musil
	Comment 5 • 26 years ago

Reassigning all OJI bugs to george.drapeau@eng.sun.com

	leger
	Comment 6 • 25 years ago

Moving to M11...not an M10 blocker.

	Warren Harris
	Comment 7 • 25 years ago

There's already a pref for whether to run java or not. Maybe it should be a
tri-state: yes, no, no-but-ask.

The situation of visiting a page and not noticing that there's supposed to be
an applet running right now, but your pref is disabled can be greatly improved
by putting a rectangle on the screen with a "broken applet" icon. This is
something we never got around to doing in 4.x.

	drapeau
	Comment 8 • 25 years ago

One small modification on the "broken applet" graphic: perhaps a different
graphic for the specific case of "you have a JVM but you've chosen to disable it
so I'm not going to run this applet for you" would be more appropriate,
informative, and less confusing to customers.

	Warren Harris
	Comment 9 • 25 years ago

Agreed. It would be nice if had a "run it anyway" button on it too. In fact if
you had this, you wouldn't need the "no-but-ask" state in the prefs dialog.

	Matthew Tuck [:CodeMachine]
	Comment 10 • 25 years ago

This is covered as a part of bug #7380.  A user could set "enable java" to
"prompt", and would be prompted every new page.  However the dialog would have
the capability to remember the decision.  So for example, if you were at
"http://www.mozilla.org/projects/seamonkey/" you could remember this for
"http://www.mozilla.org/projects/seamonkey/", "http://www.mozilla.org/projects/"
or "http://www.mozilla.org/".  This would automatically alter the rules so in
future these sites would either be disabled or enabled.

I suggest no ad hoc mechanisms be introduced when there are general mechanisms
that could be implemented (and are very popular judging on the number of votes
it has).

	chris hofmann
	Comment 11 • 25 years ago

m12

	edburns
	Comment 12 • 25 years ago

I like Warren's suggestion from  10/9.

	edburns
	Comment 13 • 25 years ago

The file that sets the preference is

mozilla\modules\libpref\src\init\all.js

	edburns
	Comment 14 • 25 years ago

The first reference to Java occurrs here:

nsJSEnvironment::nsJSEnvironment() line 851 + 31 bytes
nsJSEnvironment::GetScriptingEnvironment() line 829 + 27 bytes
NS_CreateScriptContext(nsIScriptGlobalObject * 0x014f0b74, nsIScriptContext * *
0x0101184c) line 881 + 5 bytes
nsWebShell::CreateScriptEnvironment() line 2893 + 20 bytes
nsWebShell::GetScriptGlobalObject(nsWebShell * const 0x0101183c,
nsIScriptGlobalObject * * 0x0012fa24) line 4567 + 11 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x015d6360, void *
0x004b070a, nsIDeviceContext * 0x01011040, nsIPref * 0x00c78790, const nsRect &
{...}, nsScrollPreference nsScrollPreference_kAuto) line 405 + 56 bytes
nsWebShell::Embed(nsWebShell * const 0x01011800, nsIContentViewer * 0x015d6360,
const char * 0x015d6dc0, nsISupports * 0x00000000) line 892 + 69 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x015d5050,
nsIChannel * 0x00fe3450, nsISupports * 0x00000000) line 1394 + 46 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x01017200,
nsIChannel * 0x00fe3450, nsISupports * 0x00000000) line 200
nsChannelListener::OnStartRequest(nsChannelListener * const 0x00fe36d0,
nsIChannel * 0x00fe3450, nsISupports * 0x00000000) line 1580 + 43 bytes
nsInputStreamChannel::OnStartRequest(nsInputStreamChannel * const 0x00fe3454,
nsIChannel * 0x00fe7030, nsISupports * 0x00000000) line 331
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x00cfb3c0)
line 199
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x00cfb2f0) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x00cfb2f0) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c77200) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x001e078e, unsigned int 49448, unsigned int 0,
long 13070848) line 947 + 9 bytes
USER32! 77e71250()
00c77200()


Now, when fixing this bug, and honoring the "is java enabled" preference, how
should liveconnect be affected?  Should disabling java also disable liveconnect?

	chris hofmann
	Comment 15 • 25 years ago

m13

	leger
	Comment 16 • 25 years ago

Updating QA Contact.

	chris hofmann
	Comment 17 • 25 years ago

move to m14. let me know if fixes are available. thx.

	edburns
	Comment 18 • 25 years ago

This ties in with loading the OJI dll lazily, #18277.

	edburns
	Comment 19 • 25 years ago

New feature, moving way out.

	Stephan Niemz
	Comment 20 • 24 years ago

I would definitely like this feature! Adding myself to then Cc list.

	Peter Lubczynski
	Comment 21 • 24 years ago

This is more than just a feature. The OBJECT tag should support the standby 
attribute: 

http://www.w3.org/TR/WD-html40-970708/struct/includes.html#edef-OBJECT

nominating, it should be a trivial fix.

	Peter Lubczynski
	Comment 22 • 24 years ago

*** Bug 79481 has been marked as a duplicate of this bug. ***

	shrirang khanzode
	Comment 23 • 24 years ago

wow..this is a legendary bug. qa reassign : self

	edburns
	Comment 24 • 24 years ago

*** Bug 84429 has been marked as a duplicate of this bug. ***

	edburns
	Comment 26 • 24 years ago

Posted to newsgroups:

From: Ed Burns <ed.burnsREMOVE_THIS@sun.com>
Newsgroups: netscape.public.mozilla.embedding,netscape.public.mozilla.oji
Subject: Best way to post "Starting Java" notification?
Date: 11 Jun 2001 19:18:15 -0700
Message-ID: <7cb8ziya1aw.fsf@sun.com>
--
Hi Folks,

The first part of fixing bug 1785: Prompt before starting up java, is to
write the "Starting Java..." message to the status bar.  Simon suggested
perhaps embedders might be interested in this message and I agree.  I
was planning on using nsIMsgStatusFeedback.ShowStatusMessage() to do
the work, but I'm not sure how to obtain a ref to this interface from
way down in the OJI code.  So, I have two questions:

1. How do I obtain an nsIMsgStatusFeedback instance from way down in the
OJI code?

2. How can I also notify embedders of this event?

	Peter Lubczynski
	Comment 27 • 24 years ago

Could this be a more general solutin for all plugins?

	edburns
	Comment 28 • 24 years ago

What, you mean looking at the content type and, if it's the first time this 
type has been encountered, saying something like "Starting plugin for type %s"?

That sounds fine to me.  The thing I need to know is, how do I obtain an 
nsIMsgStatusFeedback, or other interface that writes to the status bar, from 
inside nsPluginHostImpl.cpp?

Ed

	Peter Lubczynski
	Comment 29 • 24 years ago

I think nsPluginInstancePeer::ShowStatus() is supposed to do that, I thought?
That could be broken, dunno, but the call should probably go through there.

But, I really think we should just do this for APPLET or EMBED and in the case
of OBJECT, use the STANDBY attribute and have the message specified in an
embedding overridable overlay. 

I don't know much about doing that, but I think Dan does. cc:ing him.

	Dan Rosen
	Comment 30 • 24 years ago

Sorry, don't know anything about it. Honestly, if this bug were assigned to me,
I'd resolve it as WONTFIX. With "enhancements" like this, we'll need an entire
separate app to manage Mozilla prefs. Removing CC.

	edburns
	Comment 31 • 24 years ago

*** Bug 86634 has been marked as a duplicate of this bug. ***

	Peter Lubczynski
	Comment 32 • 23 years ago

Taking another look at trying to display a message on the status bar before
starting Java isn't quite a trivial because I think we need to get back to the
event loop somehow so that the status bar gets updated.

All the ways I tried seemed to funnel through  the same call to
|browserChrome->SetStatus()| which didn't seem to do the trick in Mozilla.
However, it did work in MFCEmbed, I think because it has a native status bar.

I think blake or timeless has worked with UI like this before, cc:ing for comment.

	edburns
	Comment 33 • 23 years ago

Hi Peter, thanks for investigating this.  As you know, there are two sides to 
the coin: 1. Detecting the right time when the "java is starting" "event" 
occurrs 2. Conveying that to the user.  

I thought I had a handle on 1., but now I'm not so sure.

	Peter Lubczynski
	Comment 34 • 23 years ago

Ed, you are correct, the right time is very important. I know the "long delay"
happens when we do a reflow of the frame model, inside
nsPluginHostImpl::GetPluginFactory()...at least with JRE 1.3.

I was thinking that maybe the status bar change message can be sent from the the
content model side of things. As long as it's before the frame model gets
reflowed, I'm guessing, but I'm not quite sure WHERE that should go.

Who knows more about the status bar, Jud?

	shrirang khanzode
	Comment 35 • 23 years ago

SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)

	edburns
	Comment 36 • 23 years ago

Putting on my 0.9.4 radar.

	edburns
	Comment 37 • 23 years ago

Not having a "Starting Java" message leads to user confusion.

	edburns
	Comment 38 • 23 years ago

Posted again:

Path: engnews2.Eng.Sun.COM!not-for-mail
Newsgroups: 
netscape.public.mozilla.oji,netscape.public.mozilla.plugins,netscape.public.mozi
lla.embedding
Subject: Re: Best way to post "Starting Java" notification?
Date: 17 Aug 2001 18:42:12 -0700
Message-ID: <7cb1ymaf8jv.fsf@sun.com>
11 Jun 2001: 

> The first part of fixing bug 1785: Prompt before starting up java, is
> to write the "Starting Java..." message to the status bar.  Simon
> suggested perhaps embedders might be interested in this message and I
> agree.  I was planning on using
> nsIMsgStatusFeedback.ShowStatusMessage() to do the work, but I'm not
> sure how to obtain a ref to this interface from way down in the OJI
> code.  

No one replied to this.

I'd like to get this in to 0.9.4 and I have a simple question:

How do I post a message to the status bar so that it displays to the
user IMMEDIATELY?

Here's the stack at the time I need to post the message:

nsPluginHostImpl::SetUpPluginInstance() line 3544
nsPluginHostImpl::InstantiateEmbededPlugin() line 3144 + 24 bytes
nsObjectFrame::InstantiatePlugin() line 1207
nsObjectFrame::Reflow() line 974 + 49 bytes
nsLineLayout::ReflowFrame() line 962 + 43 bytes
nsBlockFrame::ReflowInlineFrame() line 3459 + 29 bytes
[...Lots of layout kind of stuff deleted...]
nsBlockFrame::Reflow() line 797 + 15 bytes
nsContainerFrame::ReflowChild() line 726 + 31 bytes
CanvasFrame::Reflow() line 563
nsBoxToBlockAdaptor::Reflow() line 866
nsBoxToBlockAdaptor::DoLayout() line 523 + 52 bytes
nsBox::Layout() line 986
nsScrollBoxFrame::DoLayout() line 379
nsBox::Layout() line 986
nsContainerBox::LayoutChildAt() line 591 + 16 bytes
nsGfxScrollFrameInner::LayoutBox() line 1036 + 17 bytes
nsGfxScrollFrameInner::Layout() line 1143
nsGfxScrollFrame::DoLayout() line 1044 + 15 bytes
nsBox::Layout() line 986
nsBoxFrame::Reflow() line 903
nsGfxScrollFrame::Reflow() line 733 + 25 bytes
nsContainerFrame::ReflowChild() line 726 + 31 bytes
ViewportFrame::Reflow() line 538
nsHTMLReflowCommand::Dispatch() line 145
PresShell::ProcessReflowCommand() line 5850
PresShell::ProcessReflowCommands() line 5905
PresShell::FlushPendingNotifications() line 4877
nsEventStateManager::FlushPendingEvents() line 3929
nsEventStateManager::GenerateDragGesture() line 1133
nsEventStateManager::PreHandleEvent() line 351
PresShell::HandleEventInternal() line 5644 + 43 bytes
PresShell::HandleEvent() line 5575 + 25 bytes
nsView::HandleEvent() line 377
nsView::HandleEvent() line 350
nsView::HandleEvent() line 350
nsViewManager::DispatchEvent() line 2058
HandleEvent() line 68
nsWindow::DispatchEvent() line 728 + 10 bytes
nsWindow::DispatchWindowEvent() line 749
nsWindow::DispatchMouseEvent() line 4262 + 21 bytes
ChildWindow::DispatchMouseEvent() line 4514
nsWindow::ProcessMessage() line 3198 + 24 bytes
nsWindow::WindowProc() line 996 + 27 bytes
USER32! 77e71268()

In nsPluginHostImpl::SetUpPluginInstance()
{
//...
        result = plugin->CreateInstance(NULL, kIPluginInstanceIID, (void **)
&instance);
//...
}

This call to CreateInstance is where the big "freeze for at least 15
seconds" hit happens.  I'd like to put something like:

  aOwner->ShowStatus("Starting java...");

before the call to CreateInstance(), but when I do this, of course it
doesn't display, because we're ultimately executing on the WindowProc.
Is there any way to force the event loop to be processed?

Thanks,

Ed

-- 
Remove REMOVE_THIS from email address before replying.
These are my views, and may not be the same as Sun Microsystems Inc.

	edburns
	Comment 39 • 23 years ago

From: Rick Potts (rpotts@wwc.com)
Subject: Re: Best way to post "Starting Java" notification? 
Newsgroups: netscape.public.mozilla.oji
Date: 2001-08-17 19:55:40 PST 
 


The standard way of propagating status informatiion is via the 
nsIProgressEventSink interface...

Generally, you can get this interface from the document channel (or any 
channel really) by doing the following:

    nsCOMPtr<nsIInterfaceRequestor> requestor;
    nsCOMPtr<nsIProgressEventSink> eventSink;

    nsIChannel::GetNotificationCallbacks(getter_AddRefs(requestor));
    eventSink = do_GetInterface(requestor);

The downside to using nsIProgressEventSink::OnStatus(...) is that it 
expects the status code to be an id which can be translated into a 
string bundle reference :-(

Of course, the other issue is that the message probably won't be 
displayed synchronously :-(

 I can't really think of any way to force this message to display... 
 short of calling OnStatus(...), posting an event and then entering a 
sub-event-loop until the event is processed...  In fact, after thinking 
about it a bit more... i think that you would also need to push a nested 
event Q before spinning up the event loop.   This would prevent PLEvents 
from being processed out of order...

-- rick

	edburns
	Comment 40 • 23 years ago

<bryner> edburns: ok, try this
<bryner> document->GetScriptGlobalObject();
<bryner> globalObject->GetDocShell();
<bryner> QI docshell to nsIWebShell
<bryner> webshell->GetDocumentLoader();
<bryner> docloader->GetDocumentChannel();

	edburns
	Comment 41 • 23 years ago

I'm banging my head against this wall.  I've posted a followup:

Message-ID: <bbf0af98.0108211425.3d9fc7f5@posting.google.com>

Pushing back to 0.9.5.

	rpotts (gone)
	Comment 42 • 23 years ago

Hi Ed,

I finally listened to my voicemail :-)

I'll attach a patch as soon as possible which will make
PluginInstanceOwner::ShowStatus(...) synchronous...

-- rick

	rpotts (gone)
	Comment 45 • 23 years ago

Hi Ed,
I've attached a preliminary patch to make showStatus(...) synchronous for both
plugins and javascript.

Let me know if this fixes your ShowStatus(...) woes :-)

-- rick

	edburns
	Comment 46 • 23 years ago

I have created bug 97380 to handle the no user interaction part of this bug.

	edburns
	Comment 47 • 23 years ago

Ressign to Joe Chou, as I am no longer working officially on OJI.

	Peter Lubczynski
	Comment 48 • 23 years ago

I think this was FIXED a while ago....

	Patty Mac
	Comment 49 • 23 years ago

Verified on the branch build (2001-10-09-10-0.9.4)

	David G King
	Comment 50 • 23 years ago

I'm reopening this bug as I don't see a message about starting Java on the
status bar with Win98SE with build 2002071704-TRUNK.

	Jo Hermans
	Comment 51 • 22 years ago

*** Bug 166536 has been marked as a duplicate of this bug. ***

	Eugene Savitsky
	Comment 52 • 22 years ago

*** Bug 166536 has been marked as a duplicate of this bug. ***

	Boris 'pi' Piwinger
	Comment 53 • 22 years ago

Hm, this bug has a patch a target milestone in the far past and high priority.
Is there a chance to make the patch work in current trunk and get it going?

pi

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 54 • 22 years ago

pi, while this bug does have a patch, it is not for the issue that comment 0
mentions.

	Joshua Xia
	Comment 55 • 22 years ago

reassign to me

	Joshua Xia
	Comment 56 • 22 years ago

->p4

	Pete Zha
	Comment 57 • 22 years ago

add "on-the-fly" to white board

	Gabriel Barros
	Comment 58 • 22 years ago

Wow, this bug is ancient.

Anyway. I think that the best solution for this "bug" is to have a list of
"allow/deny" domains for java, like it's done with popups, for example. I think
that 99% of the people that surfs with java disabled, only enable it for his/her
online bank.

If someone can points me out some good reading in the line of "mozilla hacking
for dummies" :) and where's the code that decides to startup java, i can try to
give a hand.

	Kathleen :Brade Reporter
	Comment 59 • 22 years ago

Gabriel Barros (comment 58) -- Please don't take offense but that is not what I
filed this bug about.  I don't care about sites; I want to know if I'm about to
lock up my computer while Java starts up and be able to cancel it.  There is
nothing wrong with your idea.  I think you should file a new bug with your
suggestion and make it depend on this bug.

	Joshua Xia
	Comment 60 • 22 years ago

Preferences->Advanced->Enable Java (checkbox) can meet this requirement?

	Joshua Xia
	Comment 61 • 22 years ago

*** Bug 78159 has been marked as a duplicate of this bug. ***

	Joshua Xia
	Comment 62 • 21 years ago

->kyle

	Kyle Yuan
	Comment 63 • 21 years ago

Bug 19118 is talking about a general Plugin manager that can disable a
particular plugin/mimetype from working. But I'm afraid it won't be able to
disable a plugin for some paticular sites.

	Dave Miller [:justdave]
	Comment 64 • 20 years ago

only drivers should be granting blocking flags  You can request it if you want
(set it to "?").

	Pete Zha
	Comment 65 • 19 years ago

mass reassign to Alfred

	Nochum Sossonko [:Natch]
	Comment 66 • 15 years ago

This should be invalid now that OJI has been removed from trunk.

	Benjamin Smedberg
	Comment 67 • 12 years ago

Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".