Closed Bug 632275 Opened 13 years ago Closed 13 years ago

Web Console: Error message when click on an object to create an inspect window

Categories

(DevTools :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 6

People

(Reporter: bj, Assigned: msucan)

Details

(Whiteboard: [patchclean:0412] [console-1][fixed-in-devtools][merged-to-mozilla-central])

Attachments

(1 file, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0C)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0C)

I get an error message when I click on an object to create an inspect window, but not with the command "inspect (document)". The message appears for HTML documents, but not from a XULDocument like the Add-ons Manager or about:config.

I see the error with Windows 7, Windows XP, and Ubuntu 10.10, and I saw the message with the 6 February and 7 February builds.

Reproducible: Always

Steps to Reproduce:
1. Visit a page (about:blank, about:home, about:support, cnn.com, yahoo.com, google.com, ...).
2. Open Web Console with control-shift-K.
3. Enter the command "document".
4. Click on [Object HTMLDocument].

Actual Results:  
The inspect window appears, but there is also a message in the web console:

[21:29:26.183] Non-standard document.width was used. Use standard document.body.clientWidth instead. @ http://www.google.com/

Expected Results:  
The inspect window appears without an error message in the web console.
Thanks for reporting this B.J. !
Status: UNCONFIRMED → NEW
Ever confirmed: true
Regression window: 

Build Worked:

Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101010 Firefox/4.0b8pre

http://hg.mozilla.org/mozilla-central/rev/26c47ba8064f

Build broken: 


Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

http://hg.mozilla.org/mozilla-central/rev/297086a0fb61

Pretty strange that beta7 RC is broken, and still beta8pre worked..
hope it helps
Assignee: nobody → mihai.sucan
Blocks: devtools4
Funny bug.

This warning started showing up since we pushed the patches for window IDs (bug 603706 or bug 606498 - can't remember which). I didn't notice back then, but the problem is really simple: when you open the Object Inspector for the "document" object, you get the list of all properties, including document.width. Whenever you read document.width you also get a warning.

The warning origin is that of the document being inspected, hence it is displayed in the Web Console.

Not sure what we can do about this, actually. Should we skip the listing of "width" from HTMLDocument objects? Or do we mark this bug as WONTFIX?
Hardware: x86 → All
Version: unspecified → Trunk
annoying. I've seen it too. It'd be nice if we could somehow suppress that error message. Or annotate it to explain why it's showing up.
(In reply to comment #4)
> annoying. I've seen it too. It'd be nice if we could somehow suppress that
> error message. Or annotate it to explain why it's showing up.

I would suggest suppressing the message by avoiding to read document.width at all. It's deprecated and we shouldn't show it in document object inspection. If this sounds fine for you, I can submit a patch.

An uglier hack would be to suppress CSS parser messages while the Property Panel opens up for HTMLDocument objects.
Is there any way to notice that document.width is a getter and not just a simple attribute? I worry about this now that getters are going to become more common... we don't want to call getter functions.

Beyond that, I think Mihai's suggestion of treating document.width specially is okay for at least eliminating this error.
No longer blocks: devtools4
for (var key in document) { 
  if (document.__lookupGetter__(key)) // do something with this key
}

We could get a list of getters for a given object with this and then do something special with them.
Attached patch proposed fix (obsolete) — Splinter Review
This is the proposed patch.

It skips document.width/height and shows Getter when the property has a getter, so we don't execute non-native getters, to not affect the web application state. Also included a mochitest.

(Wrt. a better UI for all this... we'll need to do it once we redesign/rewrite the property panel UI.)

Looking forward to your feedback. Thanks!
Attachment #518736 - Flags: feedback?(rcampbell)
Status: NEW → ASSIGNED
Whiteboard: [patchclean:0311]
Comment on attachment 518736 [details] [diff] [review]
proposed fix

+const NATIVE_FUNCTION_REGEX = /^function\s*[a-z0-9_A-Z]*\(\)\s*\{\s*\[native code\]\s*\}$/;

Please comment this so future versions of ourselves and others can figure out what you're matching with a minimum of consternation.

I think this can be simplified a little too. Can we not replace [a-z0-9_A-Z]* with \w* ?

https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Regular_Expressions

+    // Also skip non-native getters.
+    getter = aObject.__lookupGetter__(propName);
+    if (getter && !isNativeFunction(getter)) {
+      value = "";
+      presentable = {type: TYPE_OTHER, display: "Getter"};
+    }

Kind of weird. I guess we won't see a value next to the property name for these? Probably sensible since we can't be sure of side-effects.

Tests look good.

f+ with nits addressed.
Attachment #518736 - Flags: feedback?(rcampbell) → feedback+
(In reply to comment #9)
> Comment on attachment 518736 [details] [diff] [review]
> proposed fix
> 
> +const NATIVE_FUNCTION_REGEX = /^function\s*[a-z0-9_A-Z]*\(\)\s*\{\s*\[native
> code\]\s*\}$/;
> 
> Please comment this so future versions of ourselves and others can figure out
> what you're matching with a minimum of consternation.

Yeah.

> I think this can be simplified a little too. Can we not replace [a-z0-9_A-Z]*
> with \w* ?

Agreed. It seems to work.

> https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Regular_Expressions
> 
> +    // Also skip non-native getters.
> +    getter = aObject.__lookupGetter__(propName);
> +    if (getter && !isNativeFunction(getter)) {
> +      value = "";
> +      presentable = {type: TYPE_OTHER, display: "Getter"};
> +    }
> 
> Kind of weird. I guess we won't see a value next to the property name for
> these? Probably sensible since we can't be sure of side-effects.

The code needs that value and I can't give it any value, so I used "". Added a comment to mention that value is not displayed.


> f+ with nits addressed.

Thanks! Will update the patch now.
Attached patch updated patch (obsolete) — Splinter Review
Updated the patch as requested by Robert. Thanks for the f+!

Asking for review from Dolske.
Attachment #518736 - Attachment is obsolete: true
Attachment #519171 - Flags: review?(dolske)
Whiteboard: [patchclean:0311] → [patchclean:0314]
Whiteboard: [patchclean:0314] → [patchclean:0314] [console-1]
Comment on attachment 519171 [details] [diff] [review]
updated patch

Asking for review from Dave Camp. Thanks!
Attachment #519171 - Flags: review?(dolske) → review?(dcamp)
Comment on attachment 519171 [details] [diff] [review]
updated patch

>+function isNativeFunction(aFunction)
>+{
>+  return NATIVE_FUNCTION_REGEX.test(aFunction.toSource());
>+}

As discussed in IRC, checking (typeof aFunction == 'function' && 'prototype' in aFunction) is probably a better test for native-function-ness.

We also discussed in IRC that a better approach to solving the general problem (trusting browser-provided getters but not content-provided getters) would be to enumerate the xray wrapper first (trusting getters on that) and then enumerate the unwrapped object (not trusting getters).  Mihai's going to file a follow up bug on that.

With the change to isNativeFunction() and a comment pointing at the followup bug for enumerating the unwrapped object, I'd give my f+/r+/whatever I'm qualified to give+.
Attached patch patch update 2 (obsolete) — Splinter Review
Updated the patch as requested. Thanks for your review, Dave!

I reported the follow up bug 647235.

Please let me know if further changes are needed.
Attachment #519171 - Attachment is obsolete: true
Attachment #523604 - Flags: review?(dcamp)
Attachment #519171 - Flags: review?(dcamp)
Whiteboard: [patchclean:0314] [console-1] → [patchclean:0401] [console-1]
Comment on attachment 523604 [details] [diff] [review]
patch update 2

There's one more catch of using 'is this a native function' as the heuristic for deciding "safe" (dom-provided) getters, which is that functions created with Function.prototype.bind() are considered native.  So a getter created with obj.__defineGetter__('foo', bar.bind({})) will be executed with this test.

This still strikes me as better than what's there now, and there's a followup filed for figuring out a better solution.  r+, forwarding to dolske for a binding r+.
Attachment #523604 - Flags: review?(dolske)
Attachment #523604 - Flags: review?(dcamp) → review+
Comment on attachment 523604 [details] [diff] [review]
patch update 2

Changing reviewer to Shawn.
Attachment #523604 - Flags: review?(dolske) → review?(sdwilsh)
(In reply to comment #13)
> >+function isNativeFunction(aFunction)
> >+{
> >+  return NATIVE_FUNCTION_REGEX.test(aFunction.toSource());
> >+}
> 
> As discussed in IRC, checking (typeof aFunction == 'function' && 'prototype' in
> aFunction) is probably a better test for native-function-ness.
I do not believe this to be correct, actually.  I ran some tests in the console:
[15:00:07.201] function foo() { let i = 0; return i++; }
[15:00:07.204] undefined
--
[15:00:12.785] foo()
[15:00:12.787] 0
--
[15:00:23.257] typeof foo
[15:00:23.259] "function"
--
[15:00:32.329] 'prototype' in foo
[15:00:32.331] true
--
[15:08:34.723] foo.toSource()
[15:08:34.725] "function foo() {var i = 0;return i++;}"

My function foo meets the two criteria that the current patch has, but is clearly not a native function.  I'm assuming that by "native function" we mean implemented in C++ code.
(In reply to comment #13)
> As discussed in IRC, checking (typeof aFunction == 'function' && 'prototype' in
> aFunction) is probably a better test for native-function-ness.

Err, to clarify - I meant !('prototype' in aFunction), that was a typo (and it's correct in the patch).
dcamp has pointed out that his comment contained a typo that the patch did not (namely, that it should be negated).  I've confirmed that this works:
[15:15:25.317] dump.toSource()
[15:15:25.319] "function dump() {[native code]}"
--
[15:15:35.517] typeof dump
[15:15:35.519] "function"
--
[15:15:44.789] 'prototype' in dump
[15:15:44.791] false
Comment on attachment 523604 [details] [diff] [review]
patch update 2

>+++ b/toolkit/components/console/hudservice/PropertyPanel.jsm
> /**
>+ * Tells if the given function is native or not.
>+ *
>+ * @param function aFunction
More verbosity please

>+ * @return boolean
>+ *         True if the given funct
I think you are missing some text here

>+++ b/toolkit/components/console/hudservice/tests/browser/browser_webconsole_bug_632275_getters_document_width.js
>@@ -0,0 +1,92 @@
>+/* ***** BEGIN LICENSE BLOCK *****
>+ * Version: MPL 1.1/GPL 2.0/LGPL 2.1
>+ *
>+ * The contents of this file are subject to the Mozilla Public License Version
>+ * 1.1 (the "License"); you may not use this file except in compliance with
>+ * the License. You may obtain a copy of the License at
>+ * http://www.mozilla.org/MPL/
>+ *
>+ * Software distributed under the License is distributed on an "AS IS" basis,
>+ * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+ * for the specific language governing rights and limitations under the
>+ * License.
>+ *
>+ * The Original Code is Web Console test suite.
>+ *
>+ * The Initial Developer of the Original Code is
>+ * The Mozilla Foundation.
>+ * Portions created by the Initial Developer are Copyright (C) 2011
>+ * the Initial Developer. All Rights Reserved.
>+ *
>+ * Contributor(s):
>+ *   Mihai Sucan <mihai.sucan@gmail.com>
>+ *
>+ * Alternatively, the contents of this file may be used under the terms of
>+ * either the GNU General Public License Version 2 or later (the "GPL"), or
>+ * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
>+ * in which case the provisions of the GPL or the LGPL are applicable instead
>+ * of those above. If you wish to allow use of your version of this file only
>+ * under the terms of either the GPL or the LGPL, and not to allow others to
>+ * use your version of this file under the terms of the MPL, indicate your
>+ * decision by deleting the provisions above and replace them with the notice
>+ * and other provisions required by the GPL or the LGPL. If you do not delete
>+ * the provisions above, a recipient may use your version of this file under
>+ * the terms of any one of the MPL, the GPL or the LGPL.
>+ *
>+ * ***** END LICENSE BLOCK ***** */
http://www.mozilla.org/MPL/boilerplate-1.1/pd-c please

r=sdwilsh
Attachment #523604 - Flags: review?(sdwilsh) → review+
Attached patch patch update 3 (obsolete) — Splinter Review
Updated as requested. I don't know how I managed to break that jsdoc comment - fixed now. Thanks Shawn!
Attachment #523604 - Attachment is obsolete: true
Whiteboard: [patchclean:0401] [console-1] → [patchclean:0412] [console-1] [checkin]
Whiteboard: [patchclean:0412] [console-1] [checkin] → [patchclean:0412] [console-1][in-devtools][merge-m-c]
Comment on attachment 525451 [details] [diff] [review]
patch update 3

http://hg.mozilla.org/projects/devtools/rev/1fe294269d54
Attachment #525451 - Attachment description: patch update 3 → [in-devtools] patch update 3
Whiteboard: [patchclean:0412] [console-1][in-devtools][merge-m-c] → [patchclean:0412] [console-1][fixed-in-devtools][merge-m-c]
Whiteboard: [patchclean:0412] [console-1][fixed-in-devtools][merge-m-c] → [patchclean:0412] [console-1][orange]
backed out in http://hg.mozilla.org/projects/devtools/rev/0bcb4052e18c

likely culprit of the backout is this bug.

run a full mochitest-browser-chrome suite to see the error.

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_inspector_domPanel.js | domPanel shows the correct value for rand1302649245940
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_inspector_domPanel.js | domPanel shows the correct tagName
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_inspector_highlighter.js | Test timed out
Attachment #525451 - Attachment description: [in-devtools] patch update 3 → patch update 3
It seems that __lookupGetter__ is not available on some DOM objects that are used by the DOM Inspector tool.

Updated the patch. Tests pass locally, but I will push to the try server.
Attachment #525451 - Attachment is obsolete: true
Whiteboard: [patchclean:0412] [console-1][orange] → [patchclean:0412] [console-1][checkin]
Comment on attachment 525732 [details] [diff] [review]
[checked-in][in-devtools] patch update 4

Pushed:
http://hg.mozilla.org/projects/devtools/rev/cbd3cdb82da2
Attachment #525732 - Attachment description: patch update 4 → [in-devtools] patch update 4
Whiteboard: [patchclean:0412] [console-1][checkin] → [patchclean:0412] [console-1][fixed-in-devtools]
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [patchclean:0412] [console-1][fixed-in-devtools] → [patchclean:0412] [console-1][fixed-in-devtools][merged-to-mozilla-central]
Target Milestone: --- → Firefox 6
Comment on attachment 525732 [details] [diff] [review]
[checked-in][in-devtools] patch update 4

http://hg.mozilla.org/mozilla-central/rev/1fe294269d54
Attachment #525732 - Attachment description: [in-devtools] patch update 4 → [checked-in][in-devtools] patch update 4
VERIFIED FIXED ON:
Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110511 Firefox/6.0a1
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110512 Firefox/6.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110511 Firefox/6.0a1
Status: RESOLVED → VERIFIED
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: