User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-cn; rv:1.9b5pre) Gecko/Locked Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-cn; rv:1.9b5pre) Gecko/Locked Minefield/3.0pre - Build ID: 2008040813 Google notebook add-on version tested as broken: 1.0.0.18/19 Reproducible: Always Steps to Reproduce: 1.click on the notebook icon on status bar 2.OR click on "Note this" item in context menu Actual Results: In "1": a new Firefox window (e.g., instance) comes out with the notebook popped up in the new instance In "2": same as in "1", plus the page is not added into Google notebook Expected Results: For "1": Notebook should pop out just above the Notebook icon in the same Firefox window For "2": Notebook should pop out and the page (or the selected page contents) should be added into Google notebook - a new Firefox instance is generated even with Tab Mix Plus's single window mode - I've tried clean profiles with the same problems. However, this DOES NOT happen to Firefox 4 preliminary trunks. (And of course not to Firefox 2) Related discussions: http://groups.google.com/group/Google-Labs-Notebook/browse_thread/thread/7d4a78a94bdd1302 http://groups.google.com/group/mozilla.feedback.firefox/browse_thread/thread/aaad6ea6c545a8bf/8ef4d74c6260cac3 http://forums.mozillazine.org/viewtopic.php?p=3331039#3331039 The third links to mozillazine forum topic started by me. There, rjonna pointed out: >The problem is not with the Google Notebook.They use a css style attribute >"position:fixed" in their popup. It is not rendering properly in Firefox 3.0. It works in FF 2.0 perfectly. >Check out the link below which exactly shows the problem. >http://www.rjonna.com/firefoxbug/bug.htm >It would be really great if this is fixed.

I looked at this a bit on Monday. It broke sometime between the March 16 preb5 trunk build and the March 24 pre-b5 trunk build. It looked like the browser XUL element was dispatching spurious load events--load events before the contents had actually loaded. The Notebook extension gets the event, realizes that something's wrong because the window hasn't loaded yet , and tries to fail gracefully by opening a new window. But this is all half-tested speculation...i wouldn't want anyone to slip on a red herring. ;) Let me know if any info from the Google side is needed to fix this.

I see this also, for the record. I will be hosed if this does not get fixed, sorry to complain.

Can confirm: Google Notebook was broken by upgrade to 3.0b5. It was working in 3.0b4.

Here too. Working correctly with version 3.0b4. Don't work anymore since 3.0b5. same problem. Notebook open in a new window (Mac and Windows) and the right click button doesn't create a new item anymore with the selected content. Hopes that MozTeam will make a quickfix.

For me it was also working well in 3b4, and is not working in 3b5. This is a great addon, so I'm really waiting for a fix ;)

Same problem for me, on Linux (Fedora 6 on x86). FF 3beta4 was fine, FF 3beta5 isn't. Wish I knew how to fix it or I'd do it myself; the Clip feature is really handy!

Also seeing this on FF3b5/Mac OS 10.5

Google Notebook not working with Firefox beta 5 on Windows XP Pro SP2.

Johnny, can you take a look at this? Dunno what's going on here, but we need some investigation.

jst ^^^

(In reply to comment #1) > I looked at this a bit on Monday. It broke sometime between the March 16 preb5 > trunk build and the March 24 pre-b5 trunk build. > Nick - any chance you can get us a shorter regression range?

Mike, here's a brief timeline on when this regressed: Mar 17 nightly--everything looks great. Mar 18 nightly--everything is completely broken. The javascript in the exception fails to load at all, labels don't show up on the status bar, and there seem to be lots of other problems with the build. Mar 21 nightly--Most of the brokenness is fixed. But the extension has the behavior you see today, as described in the bug report. I don't have any idea whether the major brokenness on March 18th is related to the current bug, but that major brokenness makes it hard to narrow the range. Hope that helps.

The bug that "broke" this extension was bug 418356. What happened there was that we limited what scripts can be loaded using the subscript loader on 3/17 such that only scripts loaded through chrome:// were allowed. That boke this extension completely. Then on 3/20 we re-enabled loading of scripts through file:// URIs (in the same bug), but when doing so the decision on whether the script gets automatic security wrappers is now based on the loading code rather than the URI of the script being loaded. What that means is that this extension used to run w/o automatic security wrappers, now it runs with automatic security wrappers, and is hitting a bunch of exceptions due to that. Chances are that this is something that has to be fixed in the extension, and it's all obfuscated code so it's not exactly trivial to see what exactly needs fixed. Damon, do we have contacts at Google for this extension?

Thanks, Johnny. any chance you could give me access to read the bug you pointed out? I'm still not clear on what the recommended way to fix this is. Is there a magic incantation to turn off the automatic security wrappers when we load a script? Also, is there any public documentation on this that you can point me to? Last time I checked, http://developer.mozilla.org/en/docs/mozIJSSubScriptLoader reads: "The specified script is executed with the system principal, meaning that there are no restrictions on what it can do." which appears to contradict what you're saying here. And as far as I know, most Google-made extensions use mozIJSSubScriptLoader to load Javascript via file:// urls. (The code should be in the components directory of any Google extension; it's unobfuscated.)

It looks like the problem is in the following matter: The Notebook opened in a small window writes a property _GN_interface to its contentWindow (doc.getElementById("gtb-gnotes-ifr").contentWindow), by means of which the extension communicates with the script in the window. When the small window is loaded, extension tries to access that property. In Firefox 3.0b5 the contentWindow appears to be wrapped in XPCNativeWrapper and that property becomes inaccessible from the extension. Moreover, it seems to be inaccessible via contentWindow.wrappedJSObject, which looks like a bug to me. Please, could you clarify, if this is an intended behaviour, i.e. if the extension really must not have access to a arbitrary property of contentWindow?

Oleg, the Firefox code is working as expected in that case. It's not that you don't have access to what you want, the problem is the other way around, that what you're accessing may not be what you think it is, which could lead to security problems etc. Accessing the property through contentWindow.wrappedJSObject *is* supposed to work, the fact that it does work is not a bug. When you do that you're guaranteed that any code that runs as a result of you touching properties and/or calling functions in the untrusted content window will run with the privileges of the untrusted content window, *not* as chrome. I'm happy to talk more about how you guys can fix this, either here or in email (though I'll be out or reach until Tuesday 4/29).

(In reply to comment #14) > Thanks, Johnny. any chance you could give me access to read the bug you pointed > out? Done. > I'm still not clear on what the recommended way to fix this is. Is there a > magic incantation to turn off the automatic security wrappers when we load a > script? Yes, but you really don't want to do that. Trust me. > Also, is there any public documentation on this that you can point me to? Last > time I checked, > http://developer.mozilla.org/en/docs/mozIJSSubScriptLoader > reads: > "The specified script is executed with the system principal, meaning that there > are no restrictions on what it can do." > which appears to contradict what you're saying here. That's still true, there are no limits about what you can do, but there are sometimes wrappers etc you *want* to use to avoid writing exploitable code, and you get those wrappers by default. > And as far as I know, most > Google-made extensions use mozIJSSubScriptLoader to load Javascript via file:// > urls. (The code should be in the components directory of any Google extension; > it's unobfuscated.) The google extensions that do that may or may not need any changes, but they'll for sure be more secure now than they were before bug 418356 was fixed.

FF3b5 as distributed with Ubuntu 8.04 also shows this issue.

21 votes already, can this bug be confirmed at least?

Confirmed, but as this really doesn't look like a bug in Firefox itself, we should probably close it out unless someone can show that this really is something that needs fixed in our code and not in the extension.

Any news on this ? I have test with the latest pre build and get the same thinks.

I'm just tested with the 3.0 RC 1 and the situation is the same : Open Bloc Notes open in a new window Browser. Any fix ?

Please read this bug before commenting. This is *not* a Firefox bug, it is a bug in the Google Notebook add-on, and Google is working on the problem.

Yes, we'll update this bug when we have it fixed at the Google end. I don't know what the Mozilla bug-closing protocol is, but we should probably leave this open until the fix is live.

Thanks for the update Nick. Yes, we can keep this open until an update add-on is available.

This should be all set.

I have just download the new version 1.0.0.20 after an exchange with Nick and it works now perfectly under Firefox 3 RC 1 (Windows). Thanks to all and specially to Mozilla and Google Team for all there great work.

I've just tried it under the 3b5 release (current with Ubuntu Gutsy Gibbon) and it works fine too. This does not show up if you run the "check for updates" on the plugins yet, you have to go to http://www.google.com/tools/firefox/ and explicitly download the plugin.

Closing bug per above comments.

Verified, thanks.