Coming here from https://bugzilla.mozilla.org/show_bug.cgi?id=1418382

What I understand from this issue, is that the problem should be solved 4 years ago, but it is still present in the current FF Developer (v. 102.0b9) & Stable (v. 101.0.1) releases.

Still truncated log/error messages, without possibility to expand them. Example:

'Uncaught TypeError: can't access property "currentSrc", $(...).find(...)[0] is undefined'

Should I create a new issue for this?

(In reply to tf from comment #25)

Coming here from https://bugzilla.mozilla.org/show_bug.cgi?id=1418382

What I understand from this issue, is that the problem should be solved 4 years ago, but it is still present in the current FF Developer (v. 102.0b9) & Stable (v. 101.0.1) releases.

Still truncated log/error messages, without possibility to expand them. Example:

'Uncaught TypeError: can't access property "currentSrc", $(...).find(...)[0] is undefined'

Should I create a new issue for this?

This looks different. Here it's probably the error message that is getting altered. Would you have a test page showing this issue?

Hi Nicolas, thank you so much for your fast response! Sure, take a look at the console on this pen: https://codepen.io/thomas-frobieter/pen/mdXYoew

I got a 'Uncaught TypeError: $(...).find(...)[0] is undefined'

(In reply to tf from comment #27)

Hi Nicolas, thank you so much for your fast response! Sure, take a look at the console on this pen: https://codepen.io/thomas-frobieter/pen/mdXYoew

I got a 'Uncaught TypeError: $(...).find(...)[0] is undefined'

Thanks for the link
So yeah, it's not related to the console: if you do the following:

try {
    let pictureCurrentSource = $(this).find('.field--name-field-coverimage img:first')[0].currentSrc;
} catch(e) {
    alert(e.message)
}

The text in the alert will contain the ...
I think it may be because the engine doesn't keep the argument of the function calls around, but I'm not sure.
Arai, is it worth opening a bug for this?

In short, if we keep the current error reporting approach, there's not much benefit for supporting parameters.
If there's much demand for showing the value, we could look into modifying the error reporting approach.

Here's the details:

The $(...).find(...)[0] string is generated by bytecode decompiler, that doesn't handle parameters and always use (...) or ().

https://searchfox.org/mozilla-central/rev/230a641415c4212fe719279263e8ddf2a411aff1/js/src/vm/BytecodeUtil.cpp#1803,1831,1956-1961

bool ExpressionDecompiler::decompilePC(jsbytecode* pc, uint8_t defIndex) {
...
  switch (op) {
...
    case JSOp::Call:
    case JSOp::CallIgnoresRv:
    case JSOp::CallIter: {
      uint16_t argc = GET_ARGC(pc);
      return decompilePCForStackOperand(pc, -int32_t(argc + 2)) &&
             write(argc ? "(...)" : "()");

The purpose of decompiler is to generate the codelet that returned the unexpected value (here, the undefined comes from the 0-th element of the value returned by find function), as a supplemental information for the error. The codelet does not represent the runtime value, but always the source code structure (or internal semantics of the source code if the source code is desugared into simpler bytecode sequence).

So, if the corresponding value comes from the code find('.field--name-field-coverimage img:first')[0], the codelet inside the error becomes find('.field--name-field-coverimage img:first')[0], but that's also available in the source pointed by the error, and IMO doesn't add much information.

On the other hand, if the code is find(query)[i], the codelet inside the error becomes find(query)[i], not find("<the content of query variable>")[0].
So, if the actual case that people want to see the value is this case, the current bytecode decompiler approach doesn't help.

If showing the actual value instead of (or in addition to) source code has more demand and more benefit, we could look into modifying the error reporting and integrate it into bytecode decompiler. for example, let it generate find(query /* = "<the content of query variable>" */)[i /* = 0 */] string.

The another possibility I can think of is to integrate the error reporting more with debugger, instead of just using string-based error message,
but if it's inside the debugger's context, the value is available by pausing at the exception and inspecting the variable.

Then, I want to know what the actual context the content of the string become necessary is.
(assuming the code above is just a minimal/simplified example)
If there's another and better way to inspect the value (such as, using debugger), that should be the way to go, instead of looking into error reporting.

Anyway, if you want to file a bug, please file under bug 622261.