several "Preference parsing warning" errors/warnings

[Shiva]

With noscript 2.9.0.14 I get the following error messages in console. Tested in a fresh profile with FF49.0.1 portable and only noscript installed.
Any ideas whats causing this and how to fix it?

** Preference parsing warning (line 37) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 39) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 82) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence **

A diff with the latest dev build revealed that apart from version strings there are now code changes compared to the release version, so no use in trying that.

Thanks

[therube]

Got me hanging, https://dxr.mozilla.org/mozilla-central ... ad.cpp#433 ?

[PLD]

I saw the same thing after a FF update and tracked it back to NoScript the same way as Shiva. I assume all FF 49.0.1 + NS users are seeing this due to https://bugzilla.mozilla.org/show_bug.cgi?id=278878#c6 ? It looks like the change only added browser console messages, it is a warning, and it tells you it is preserving the escape sequence. So maybe we are operationally OK?

[barbaz]

What are those line numbers from? There is nothing even remotely resembling an escape sequence at those lines in defaults/preferences/noscript.js

[barbaz]

Ok no it looks like there really might be problems with that file.

Some possibly wrong escape sequences:
Line 123 \-
Line 125 \?
Line 168 \?
Line 266 \'
Line 273 \/ \b \(
Line 286 \/
Line 306 \w \d

In all cases the \ appear to be meant as \\

This was just a quick search on

Code: Select all

/\\[^\\rn"]/

and going by Gvim syntax highlighting.

[PLD]

I don't know why but lineNum is a local variable which is set to 0 every call to PREF_ParseBuf (rather than being stored in PrefParseState). PREF_ParseBuf can be called multiple times in ReadExtensionPrefs(nsIFile *aFile):

https://dxr.mozilla.org/mozilla-release ... es.cpp#685

Code: Select all

PrefParseState ps;
PREF_InitParseState(&ps, PREF_ReaderCallback, nullptr);
while (NS_SUCCEEDED(rv = stream->Available(&avail)) && avail) {
  rv = stream->Read(buffer, 4096, &read);
  if (NS_FAILED(rv)) {
    NS_WARNING("Pref stream read failed");
    break;
  }

  PREF_ParseBuf(&ps, buffer, read);
}
PREF_FinalizeParseState(&ps);

Read 1st buffer: noscript.js offset 0 = file line #1. That is lineNum = 0. So:

** Preference parsing warning (line 37) => 1 + 37 => noscript.js line #38
** Preference parsing warning (line 39) => 1 + 39 => noscript.js line #40
** Preference parsing warning (line 82) => 1 + 82 => noscript.js line #83

Read 2nd buffer: noscript.js offset 4096 = file line #86. That is lineNum = 0. So:

** Preference parsing warning (line 37) => 86 + 37 => noscript.js line #123
** Preference parsing warning (line 39) => 86 + 39 => noscript.js line #125
** Preference parsing warning (line 82) => 86 + 82 => noscript.js line #168

Read 3rd buffer: noscript.js offset 8192 = file line #194. That is lineNum = 0. So:

** Preference parsing warning (line 5) => 194 + 5 = noscript.js line #199
** Preference parsing warning (line 18) => 194 + 18 = noscript.js line #212

Read 4th buffer: noscript.js offset 12288 = file line #268. That is lineNum = 0. So:

** Preference parsing warning (line 5) => 268 + 5 = noscript.js line #273
** Preference parsing warning (line 18) => 268 + 18 = noscript.js line #286

Bold ones match your findings. After a couple of edits to correct my initial mistakes. I hope

[barbaz]

The Browser Console (Ctrl-Shift-J) "flattens" identical messages, just displaying once along with their count. You sure it didn't mislead you a bit?

This is what I get from the Error Console in SeaMonkey -

Code: Select all

** Preference parsing warning (line 37) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 39) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 39) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 82) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence **

[PLD]

In order for them to be identical and collapsed the (line ##) would have to match. So I simply started with the hypothesis that there were multiple reported parsing warnings for some lines and focused on the line numbers themselves (why those appeared). Once I spotted the overlap with what you posted I thought I would share it.

When testing FF portable with just NS I got the same line numbers as OP posted (plus some collapses). However, when testing my main installed FF with NS and other extensions I get something a bit different:

** Preference parsing warning (line 6) = preserving unexpected JS escape sequence ** (2)
** Preference parsing warning (line 12) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 14) = preserving unexpected JS escape sequence ** (5)
** Preference parsing warning (line 37) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 39) = preserving unexpected JS escape sequence ** (2)
** Preference parsing warning (line 82) = preserving unexpected JS escape sequence **
** Preference parsing warning (line 5) = preserving unexpected JS escape sequence ** (4)
** Preference parsing warning (line 18) = preserving unexpected JS escape sequence ** (4)

Perhaps lines 6, 12, 14 come from another file. Not sure yet. Do you have an alternate explanation you believe to be correct?

[barbaz]

PLD, you are awesome. You nailed it. With that information, and your trick of adding 1 to the line numbers -

line 37, 39, 82 are from the 2nd buffer -> line 123, 125, 168
line 5 is from the 4th buffer -> line 273
2 of the line 18's are from the 4th buffer -> line 286
2 of the line 18's are from the 5th buffer -> line 306

Thanks much for debugging! Will get Giorgio on this if he doesn't respond by tomorrow.

Perhaps lines 6, 12, 14 come from another file. Not sure yet. Do you have an alternate explanation you believe to be correct?

They do come from another file. I tested only with NoScript enabled.

[PLD]

Oh, good catch on noscript.js line 306... I didn't follow through and try another buffer darn it. I liked the way this flowed... a real team effort! Assuming Giorgio confirms, would he be in a position to improve the Mozilla code to produce more helpful messages?

[barbaz]

Oh, good catch on noscript.js line 306... I didn't follow through and try another buffer darn it. I liked the way this flowed... a real team effort!

Assuming Giorgio confirms, would he be in a position to improve the Mozilla code to produce more helpful messages?

atm Giorgio is quite busy with WebExtensions API. I wouldn't expect him to have any time to fix other Mozilla code.

[PLD]

Yeah, why did I even say that out loud. FYI: Tracked my warnings for lines 6, 12, 14 down to Better Privacy (bprivacyprefs.js lines 4, 7, 8). It uses CRLF instead of LF so lineNum is incremented by 2 for each line.

[Giorgio Maone]

Thank you both for the awesome investigative work.
The fix will go in 2.9.5, which is hopefully a couple weeks away.

[Giorgio Maone]

Assuming Giorgio confirms, would he be in a position to improve the Mozilla code to produce more helpful messages?

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1309175

[PLD]

Thanks Giorgio! File, line, column would sure make things easier to track down.