New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 99 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Sign in to add a comment

Issue 5751: When an npruntime plugin returns the same NPObject multiple times into Chrome, the objects are not equal according to ===

Reported by, Dec 19 2008

Issue description

Chrome Version       :
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: Unknown
    Firefox 3: OK
         IE 7: OK (using COM instead of npruntime)

What steps will reproduce the problem?
1. From an npruntime plugin, return the same NPObject multiple times, for
example as a result of the getProperty callback.
2. Compare the objects in JavaScript:

var a = plugin.p; // a is an object
var b = plugin.p; // b should be the same object
if (a === b) {
  alert('objects are the same'); // this should run

What is the expected result?

The JavaScript === operator should return true for a and b. The ==, != and
!=== operators should also work as expected.

What happens instead?

The === operator returns false for a and b.

Please provide any additional information below. Attach a screenshot if

Comment 1 by, Dec 20 2008

Comment 2 by, Nov 16 2009

 Issue 27842  has been merged into this issue.

Comment 3 by, Nov 16 2009

The issue raised in 27042 also applies to JS objects passed into the NPAPI plugin.

Comment 4 by, Nov 16 2009

NPV8Object.cpp's npCreateV8ScriptObject() has the following logic to avoid re-
wrapping DOM objects:

    // Check to see if this object is already wrapped.
    if (object->InternalFieldCount() == V8Custom::kNPObjectInternalFieldCount) {
        v8::Local<v8::Value> typeIndex = object-
        if (typeIndex->IsNumber() && typeIndex->Uint32Value() == 
V8ClassIndex::NPOBJECT) {

            NPObject* returnValue = 
V8DOMWrapper::convertToNativeObject<NPObject>(V8ClassIndex::NPOBJECT, object);
            return returnValue;

but no such check exists for 'normal' javascript objects - these just get re-wrapped.  
Definitely seems like a bug.

Comment 5 by, Jan 18 2010

Labels: -Area-Misc Area-WebKit WebKit-JavaScript

Comment 6 by, Feb 11 2010

Labels: Mstone-X

Comment 7 by Deleted ...@, Jun 21 2010

Unable to reproduce.

Comment 8 by, Feb 9 2011

Please review as they list this issue as the primary reason for the GWT DEV mode plugin slowness in Chrome.  This needs to get fixed.  It's embarrassing for the Google Web Toolkit to run better on other browsers than Google Chrome...

Comment 9 by, May 3 2011

We are now on Chrome 11 and GWT 2.3.0 and the GWT Dev Mode plugin for Chrome is still painfully slow because of this issue.  This ticket has existed for two years now!  Please fix this issue!  See also:

Comment 10 by, May 3 2011

For the benefit of those arriving here from a thread discussing the GWT Dev Mode plugin performance on Chrome, please see this discussion for more info:

Comment 11 by, May 6 2011


I filed this a couple of years ago and the troubles appear to extend beyond the workarounds I made for O3D. The bug is real and not a thing that is trivial to work around. Please assign the bug (not to me). It's probably a Chromium issue rather than a V8 issue.

Comment 12 by, May 26 2011

Project Member
The following revision refers to this bug:

r86893 | | Thu May 26 13:56:50 PDT 2011

Changed paths:

Preserves NPObject identity for objects created in a plugin and passed to JavaScript. 

BUG= 5751 ,  22631 
TEST=ui_tests w/ the addition of newly added NPObjectIdentityTest.

Patch contributed by Kelly Norton (, original review:

Comment 13 by Deleted ...@, Jan 12 2012

I get many javascript exceptions using GWT in Chrome. Is there a work around of overcoming the javascript exceptions in Chrome

Comment 14 by, Jan 17 2012

I wanted to bring up the related issue of the GWT dev mode plugin for Chrome being very slow again.  The GWT team has pointed to this issue in the past as being the culprit and has indicated the the "pepper API" would possible resolve the issue.  See also:

Correct me if I'm wrong, but isn't both pepper and NaCl here now in the release branches of Chrome?  Why would this still be so slow?  Can you two teams please work together on this?

Thank you!

Comment 15 by, Aug 10 2012

Project Member
Labels: -Pri-2 Pri-3 Action-NeedsReview
Status: IceBox
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

Comment 16 by, Aug 10 2012

Status: Unconfirmed

Comment 17 by, Aug 10 2012

Maybe you should check with your own GWT team to find out why this issue causes so many problems for debugging GWT.

Comment 18 by, Aug 10 2012

Just because the issue is old doesn't mean that it's a lower priority - just that nobody on the chromium team has chosen to work on it.  As MarkO has commented, this is *very* important to us GWT users as the GWT team claims their dev mode plugin is slow in Chrome because of this issue.  However, in an earlier comment I mentioned that the GWT team had indicated that the Pepper API would probably let them get around this issue.  That's been deployed for a few releases now but I don't think they've created a pepper plugin for GWT.

I second the suggestion that the two teams at Google need to work together to get this resolved.  I'd love to help if I could, but I don't have the chops to dig in at that low of a level...

Comment 19 by, Aug 10 2012

The "Due to the age of the issue" statement seems to decrease the importance/relevance of this issue based on chromium not paying attention to it in the first place. Sounds a little biased to me. Well, at least 69 of us (and many more that I am sure did not bother starring it) think it is important indeed... I hope you give it a real try to fix it... after all, we are in your hands... for now!

Comment 20 by, Aug 12 2012

Like many of the commenters I care about this precisely because it was described as a reason why the GWT plugin for Chrome is glacial. If this issue is no longer a root cause of that, I don't much care.

Now that browser plugins for GWT are starting to feel as if they will soon be deprecated, I may cease to care anyway, but in the short term I'd still prefer a fast GWT plugin.

Comment 21 Deleted

Comment 22 by, Jan 8 2013

Firefox is basically the primary option you have for developing/testing GWT on OS X. There are other choices (older Webkit versions, OmniWeb) but those are options of last resort for me.

Comment 23 by Deleted ...@, Jan 8 2013

I guess it won't do any good but adding this comment.  It is surprising
after following the demo on Googles own developers site that you are not
able to use Chrome to test it.  I'm on a Mac and apparently Safari won't
work either.  So bottom line is that I can't use the Smart GWT stuff at
all.  Or at least develop and test it completely.  I'm not sure what next
steps I have.

Comment 24 by Deleted ...@, Jan 8 2013

Well, I did get OmniWeb and it is working.  I will say however that it appears that Chrome is now working as well.  Not sure if I changed anything in the code or not as I was trying a ton of things but for now it seems to work.

Comment 25 by, Mar 10 2013

Project Member
Labels: -Area-WebKit -WebKit-JavaScript Cr-Content-JavaScript Cr-Content

Comment 26 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Comment 27 by, Apr 6 2013

Project Member
Labels: -Cr-Content-JavaScript Cr-Blink-JavaScript

Comment 28 by, Apr 19 2013

How has this not been addressed yet?
It is just so painfully slow to develop GWT if you want to use Chrome as the test browser.

Also, just as a side note... Super Dev Mode looks terrible.
I'd much rather debug in my IDE of choice (Eclipse) as opposed to being forced to use Source Maps which I'm sure only chrome will implement.
Just hire a few guys who will only maintain the GWT browser plugins.

Comment 29 by, Aug 29 2013

It would be really nice if this could be fixed sometime this century ;-)

Comment 30 by, Oct 23 2013

I really like Chrome, but as I see it's 5 years and I have to install FF. I really don't believe that nobody have fixed it yet.

Comment 31 by, Oct 23 2013

Come on guys, this is getting stupid now... you have an entire subsection of an industry using a competing browser to develop GWT because there's a bug that's existed for 5 years in yours? A bug that's cited officially as the reason we can't use Chrome for this purpose, yet it's still marked as unconfirmed? 5 years down the line?

Comment 32 by, Oct 23 2013

I think that fixing this bug now when Chrome introduced Pepper API and slowly deprecates NPAPI doesn't have much sense. Better option would be to align current version of the plugin to use Pepper which hopefully doesn't have such bug.

Comment 33 by, Oct 23 2013

The GWT Dev plugin cannot use Pepper as calls from JS must be
synchronous/blocking, which afaict aren't supported by Pepper (for very
good reasons).

The future of GWT is superdevmode.

BTW, GWT DevMode works well in Chrome, I don't think this bug really hurts
(GWT works around it AFAIK, at least partly)
Le 23 oct. 2013 12:38, <> a écrit :

Comment 34 by, May 20 2015

Labels: -Cr-Blink-JavaScript Cr-Internals-Plugins

Comment 35 by, Oct 30 2015

Status: WontFix
npapi plugins are not supported anymore.

Comment 36 by, Oct 30 2015

7 years ends in a WontFix :)

Sign in to add a comment