Closed Bug 427902 Opened 13 years ago Closed 13 years ago
Google Notebook add-on Broken in Firefox 3 Beta 5 and later versions
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: 18.104.22.168/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.
(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?
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?
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).
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 22.214.171.124 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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.