1785 - prompt on status bar before starting up Java

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, enhancement, P4)

Description

[Kathleen :Brade]

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.)

Comment 1

[Warren Harris]

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

Comment 2

[Paul MacQuiddy]

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

Comment 3

[rubydoo123]

setting Greg as QA contact

Comment 4

[sujay]

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

Comment 5

[Alex Musil]

Reassigning all OJI bugs to [e-mail]

Comment 6

[leger]

Moving to M11...not an M10 blocker.

Comment 7

[Warren Harris]

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.

Comment 8

[drapeau]

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.

Comment 9

[Warren Harris]

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.

Comment 10

[Matthew Tuck [:CodeMachine]]

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).

Comment 11

[chris hofmann]

m12

Comment 12

[edburns]

I like Warren's suggestion from  10/9.

Comment 13

[edburns]

The file that sets the preference is

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

Comment 14

[edburns]

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?

Comment 15

[chris hofmann]

m13

Comment 16

[leger]

Updating QA Contact.

Comment 17

[chris hofmann]

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

Comment 18

[edburns]

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

Comment 19

[edburns]

New feature, moving way out.

Comment 20

[Stephan Niemz]

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

Comment 21

[Peter Lubczynski]

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.

Comment 22

[Peter Lubczynski]

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

Comment 23

[shrirang khanzode]

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

Comment 24

[edburns]

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

Comment 25

[edburns]

Attachment: tar.gz of files in fix for this bug, first iteration, just add oji.properties to en-US.jar and indicate where in code to post the message.

Comment 26

[edburns]

Posted to newsgroups:

From: Ed Burns <[e-mail]>
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: <[e-mail]>
--
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?

Comment 27

[Peter Lubczynski]

Could this be a more general solutin for all plugins?

Comment 28

[edburns]

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

Comment 29

[Peter Lubczynski]

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.

Comment 30

[Dan Rosen]

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.

Comment 31

[edburns]

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

Comment 32

[Peter Lubczynski]

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.

Comment 33

[edburns]

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.

Comment 34

[Peter Lubczynski]

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?

Comment 35

[shrirang khanzode]

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

Comment 36

[edburns]

Putting on my 0.9.4 radar.

Comment 37

[edburns]

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

Comment 38

[edburns]

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: <[e-mail]>
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.

Comment 39

[edburns]

From: Rick Potts ([e-mail])
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

Comment 40

[edburns]

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

Comment 41

[edburns]

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

Message-ID: <[e-mail]>

Pushing back to 0.9.5.

Comment 42

[rpotts (gone)]

Hi Ed,

I finally listened to my voicemail :-)

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

-- rick

Comment 43

[rpotts (gone)]

Attachment: First try at making showStatus(...) synchronous for plugins and javascript. (WIP)

Comment 44

[rpotts (gone)]

Attachment: Oops... This is the *correct* patch.

Comment 45

[rpotts (gone)]

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

Comment 46

[edburns]

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

Comment 47

[edburns]

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

Comment 48

[Peter Lubczynski]

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

Comment 49

[Patty Mac]

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

Comment 50

[David G King]

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.

Comment 51

[Jo Hermans]

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

Comment 52

[Eugene Savitsky]

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

Comment 53

[Boris 'pi' Piwinger]

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

Comment 54

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 55

[Joshua Xia]

reassign to me

Comment 56

[Joshua Xia]

->p4

Comment 57

[Pete Zha]

add "on-the-fly" to white board

Comment 58

[Gabriel Barros]

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.

Comment 59

[Kathleen :Brade]

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.

Comment 60

[Joshua Xia]

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

Comment 61

[Joshua Xia]

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

Comment 62

[Joshua Xia]

->kyle

Comment 63

[Kyle Yuan]

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.

Comment 64

[Dave Miller [:justdave]]

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

Comment 65

[Pete Zha]

mass reassign to Alfred

Comment 66

[Nochum Sossonko [:Natch]]

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

Comment 67

[Benjamin Smedberg]

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".