If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

java applets disappear when you have plugin registered with content policy

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Plug-ins
P1
normal
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: gabe, Assigned: Biesinger)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.9alpha1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1

java dissappers

Reproducible: Always

Steps to Reproduce:
1.instill extenion like adblock
2.go too a site with java

Actual Results:  
java dissappers

Expected Results:  
java should not dissapper

https://bugzilla.mozilla.org/show_bug.cgi?id=309706 stoped java from crashing with adblock but made java not work
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051109 Firefox/1.6a1 ID:2005110923

I see it happen on this site: http://www.jigzone.com/ms/z.php?k=2F4GIDD8
When I disable Adblock, the applet starts working.

Comment 2

12 years ago
Filed regarding bug 309706, comment 58.

Updated

12 years ago
Summary: java applacations dissapper when you have plugin registered with content policy → java applications disappear when you have plugin registered with content policy
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: java applications disappear when you have plugin registered with content policy → java applets disappear when you have plugin registered with content policy
Version: unspecified → Trunk
summary:
- wrapping the <object> flushes reflow
- this means that things are flushed by the time ShouldLoad is called
- we won't ever notify when the type of the plugin changes to eType_Plugin (aNotify=false)

fix:
- stop flushing reflow there
- instead, expose a method on nsIObjectLoadingContent:
  void ensurePluginLoaded();
or somesuch

implementation is something like:

   if (mType == eType_Plugin && !GetFrame()) {
     mInstantiating = TRUE;
     RecreateFramesFor(this);
     mInstantiating = FALSE;
     if (!GetFrame())
        return;
   }
   if (!GetFrame()->GEtPluginInstance())
      Instantiate(mContentType, mURI);

presshell can also call this in StartPluginInstance
Assignee: nobody → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
(btw, before bug 309706, this worked purely by chance... the type of the object defaulted to Type_Plugin for embed and applet; and mURI/mContentType was already correct by the time ShouldLoad was called. for <object>, the bug should have already been there.)

Is there an adblock version which works in seamonkey? where can I get adblock?
(Reporter)

Comment 5

12 years ago
http://forums.mozillazine.org/viewtopic.php?t=266291&highlight=

it has the latest adblock stuff
(Reporter)

Comment 6

12 years ago
 Greasemonkey also casues same problem for some ppl
ohh, bz, you'll like this. even if I do fix what I mentioned above, it still doesn't work - checkLoad seems to set an attribute "adblockdata" on the <applet>. This notifies. This constructs frames. -> same problem happens again.
(in function storeAdblockData, component.js:589)
Created attachment 202807 [details] [diff] [review]
patch from comment 3

even though this doesn't fully fix the problem, I think we should check it in
Attachment #202807 - Flags: superreview?(bzbarsky)
Attachment #202807 - Flags: review?(bzbarsky)
> checkLoad seems to set an attribute "adblockdata" on the <applet>.

That's something the content policy API doesn't allow and something adblock needs  to stop doing if it's going to not break.  I've filed bug 316296 on documenting this clearly in nsIContentPolicy.

I'll try to review this later tonight.
Comment on attachment 202807 [details] [diff] [review]
patch from comment 3

>Index: content/base/public/nsIObjectLoadingContent.idl
>+   * instantiated. This method does nothing if the type is not #TYPE_PLUGIN.

Why the '#' there?

>Index: content/base/src/nsObjectLoadingContent.cpp
>+nsObjectLoadingContent::EnsureInstantiation()

>+  nsIObjectFrame* frame = GetFrame();

This should really flush out frames first, I think, except if we're called from ObjectURIChanged.  Could we somehow keep track of whether we're in the middle of calling NS_CheckContentLoadPolicy and flush frames if we're not?

>+    // Trigger frame construction

We _really_ don't want to do this from inside ObjectURIChanged.  I guess we don't really need the flush because RecreateFramesFor handles it for us, though.  So I'd say this function should look like:

nsIFrame* frame = GetFrame();
if (!frame) {
  if (! calling NS_CheckContentLoadPolicy) {
    recreate frames;
  }
  if (!frame) {
    return NS_OK;
  }
}

>+  // We may have a plugin instance already; if so, do nothing

Would it make sense for this method to return the nsIPluginInstance?  That's what the caller really wants, after all...  And if this method is noscript it can do that.  Either way, though.

The rest looks good.
Attachment #202807 - Flags: superreview?(bzbarsky)
Attachment #202807 - Flags: superreview-
Attachment #202807 - Flags: review?(bzbarsky)
Attachment #202807 - Flags: review-

Comment 12

12 years ago
Thanks Christian for clarying the cause and Boris for the documentation. Most of the cases have been fixed, and now the video's and java applets load on the trunk builds.

Fixed version:
http://forums.mozillazine.org/viewtopic.php?t=266291
(Reporter)

Comment 13

12 years ago
still some java dissppears on some sites
(Reporter)

Comment 14

12 years ago
http://www.jchq.net/applets/Exam/Exam.htm


does not work but atlest orginal page i used for url works
(Reporter)

Updated

12 years ago
Stuff will keep disappearing, possibly, until this bug is actually resolved fixed (that is, until that patch is updated, reviewed, and checked in).
Created attachment 204238 [details] [diff] [review]
patch v2

OK, addressed those comments. I now always set mInstantiating in ObjectURIChanged. The name for AutoSetToFalse sucks, it is a remnant of my attempt to pass it a PRBool* (which doesn't work for bitfields).

Maybe AutoSetInstantiatingToFalse?
Attachment #202807 - Attachment is obsolete: true
Attachment #204238 - Flags: superreview?(bzbarsky)
Attachment #204238 - Flags: review?(bzbarsky)
Created attachment 204302 [details] [diff] [review]
Classinfo patch

forgot to include this in the file above
Comment on attachment 204238 [details] [diff] [review]
patch v2

> Maybe AutoSetInstantiatingToFalse?

Yeah, that seems reasonable.  r+sr=bzbarsky.
Attachment #204238 - Flags: superreview?(bzbarsky)
Attachment #204238 - Flags: superreview+
Attachment #204238 - Flags: review?(bzbarsky)
Attachment #204238 - Flags: review+
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.9alpha
(Reporter)

Comment 19

12 years ago
check this pactch in on trunk
I will as soon as I have the time to watch the tree.
Created attachment 204868 [details] [diff] [review]
patch for checkin
Attachment #204238 - Attachment is obsolete: true
Attachment #204302 - Attachment is obsolete: true
Checking in content/base/public/nsIObjectLoadingContent.idl;
/cvsroot/mozilla/content/base/public/nsIObjectLoadingContent.idl,v  <--  nsIObjectLoadingContent.idl
new revision: 3.3; previous revision: 3.2
done
Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <--  nsObjectLoadingContent.cpp
new revision: 1.16; previous revision: 1.15
done
Checking in content/base/src/nsObjectLoadingContent.h;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.h,v  <--  nsObjectLoadingContent.h
new revision: 1.6; previous revision: 1.5
done
Checking in layout/base/nsPresShell.cpp;
/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.886; previous revision: 3.885
done
Checking in dom/src/base/nsDOMClassInfo.cpp;
/cvsroot/mozilla/dom/src/base/nsDOMClassInfo.cpp,v  <--  nsDOMClassInfo.cpp
new revision: 1.335; previous revision: 1.334
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Depends on: 319049
Blocks: 313687
Depends on: 319332
*** Bug 322396 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
*** Bug 322257 has been marked as a duplicate of this bug. ***

Comment 25

11 years ago
From what I understand this landed on trunk only. Any chance this can make it into 1.8 branch as well? This issue is a major annoyance for Adblock (Plus) users. For example I got a complaint about this page today: http://marriott.com/property/phototour.mi?marshaCode=mowcy&pageID=HWHOM&imageID=1
When any JavaScript content policy is installed this page makes Firefox hang (you can only close tabs, nothing more). Reproducible with Firefox 1.5.0.4 and current Firefox 2.0a3 nightlies, not with trunk nightlies however - most definitely because of this patch.
> From what I understand this landed on trunk only.

Yes, because it modifies the code added in bug 1156, which is trunk-only.  Whatever you're seeing on branch is not this bug (even if the patch in this bug did happen to fix it).  A branch fix, if possible, would have to be totally different.

Comment 27

11 years ago
Hate to say it, but this still happens for me on the latest trunk nightly (2006061405). Exact same symptoms at least (Java applets hang, only when AdBlock installed, e.g. games at pogo.com). Also using the latest AdBlockPlus (0.7.0.2) and Java (build 1.5.0_07-b03). 

Reopening (please pardon me if this is an etiquette faux pas). 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ray, please file a new bug, with exact steps to reproduce.  It's very likely you're seeing a different issue, in a totally different piece of code, especially since we did check that the patch in this bug fixes the issues this bug was filed on.  For example, bug 336875 had symptoms similar to this one, for totally different reasons.

Please do cc me on the bug you file.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago11 years ago
Resolution: --- → FIXED

Comment 29

11 years ago
FYI: I believe this is related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6396012

I feel this is a very severe bug because it takes down the entire browser every time. I can reproduce this bug under FireFox 2.0.0.3 and AdBlock Plus 0.7.2.4 but it is gone if I upgrade to FireFox 3.0 alpha 2. Can't you guys backport the fix to a FireFox 2.x release in the near future? Thank you.

Comment 30

11 years ago
(In reply to comment #29)
> Can't you guys backport the
> fix to a FireFox 2.x release in the near future? Thank you.

gili: see comment 26.  file a new bug, please.

Comment 31

11 years ago
Filed bug #375070. Thank you.

Updated

10 years ago
Depends on: 385649
Depends on: 394970

Updated

10 years ago
Duplicate of this bug: 402391

Updated

9 years ago
Blocks: 467520
You need to log in before you can comment on or make changes to this bug.