[UNRELATED] unremovable message over NS confirmation

[KIAaze]

Hi,

I often get noscript confirmation dialogs, when I want to allow some flash video to run or similar things.
However, they are almost always covered up by a yellow popup text, preventing me from clicking "allow" (or deny) without moving the window. And it seems impossible to get rid of this popup until the confirmation dialog is closed.
Example:


It's great that they are not temporary popups (like Ubuntu's error messages which disappear before you can read them...), but it would be nice if they could either be integrated into the confirmation dialog (with scrollbars for example), or disappear on clicking. Although since I usually never read them, temporary might do as well.
I could probably uncheck the "always ask" box, but I like being asked, just in case.

System info:
Ubuntu 11.04
Mozilla Firefox 7.0.1
NoScript 2.1.4rc2

[Tom T.]

It seems that you're getting the same confirmation dialog in two different languages, English and ... ? German, Dutch, and Swedish don't seem to fit.

Both boxes contain "hl=en_US", even though the blue one is in a different language, not en-US.
Please ensure that your operating system, browser, NoScript, Flash Player, etc .are all set to the same language. That's the first thing that comes to mind when you get the same message in two different languages.

Please let us know if that fixes it.

[GnomeBug]

It's Gnome, so tooltips are going to have bugs, sadly.
See this NoScript support thread:
http://forums.informaction.com/viewtopi ... s%E2%80%A6

[Tom T.]

It's Gnome, so tooltips are going to have bugs, sadly.
See this NoScript support thread:
http://forums.informaction.com/viewtopi ... s%E2%80%A6

Thanks for the reply. But it still doesn't explain why the apparently-duplicated messages were in two different languages.
Anyone have any ideas on that?

@ KIAaze: Try a different GUI on your platform?

[GµårÐïåñ]

That is a localization issue. The language of the dialog is what the localization is set to and the language of the code snippet is what language it was written in, which at the moment tag-wise at least is purely English. For example, you might call Object something in a language but in the code the tag will always be <OBJECT> regardless. Just a thought on the language discrepancy pointed out by Tom. So the yellow snippet is the actually EMBED code content, while the dialog is saying we have an error with <insert snippet> what do you want to do, so hence the apparent language difference. At least what I can tell from the screenshot.

[Tom T.]

That is a localization issue. The language of the dialog is what the localization is set to and the language of the code snippet is what language it was written in, which at the moment tag-wise at least is purely English. For example, you might call Object something in a language but in the code the tag will always be <OBJECT> regardless. Just a thought on the language discrepancy pointed out by Tom. So the yellow snippet is the actually EMBED code content, while the dialog is saying we have an error with <insert snippet> what do you want to do, so hence the apparent language difference. At least what I can tell from the screenshot.

But I don't see both at the same time. When I hover over, say, a Flash video at YouTube, the yellow snippet that starts with <EMBED> appears. Only after clicking the logo does the confirmation dialog in blue appear, that starts with "Temporarily allow ..."
Per the thread linked by GnomeBug , there was a work-around added for this bug in Gnome.

In any event, I can avoid it all merely by opening NS menu, point to Blocked Objects, and click "Temporarily allow shockwave-flash@hxxp/s.ytimg.com ... (video alphanumeric ID). Then I don't get the EMBED tag at all, only the blue NS confirmation box.

Haven't used Gnome, so don't know if it would be the same. But it's worth trying. And the NS menu, from the bottom status bar, extends up high enough to go past what's shown in the screenshot. Or use the top toolbar icon, whichever puts the menu over the boxes.

[GµårÐïåñ]

Oh yeah, the Gnome bug is valid and the work around is needed, not arguing that. I was simply making a comment limited to just the presented screenshot showing the language difference, saying that's a localization, IMO at least, the actual bug of why it pops up at all not withstanding. Sorry I didn't mean to put a too fine a focus on the language difference, just thought it might be helpful to eliminate that as an issue at least. Didn't mean to muddy the waters or add undue confusion.

[KIAaze]

The language is Esperanto.
And yes, it's exactly the same problem as http://forums.informaction.com/viewtopi ... s%E2%80%A6

There does seem to be a weird localization problem, as I once started Firefox by command-line with "LANG=en_US /usr/bin/firefox" to get it in English and the NoScript dialogs were still in Esperanto.
I haven't tried it on other platforms yet, as I rarely boot into Windows. But I could try KDE and Windows at some point.

edit: Strange: I can't reproduce the NoScript staying in Esperanto, when Firefox is in English bug, despite playing around with "LANG=en_US.utf-8" and "LC_ALL=en_US.utf-8".
Anyway, I did a few tests and found a reliable way of reproducing the bug, even when starting Firefox in English with "LC_ALL=en_US.utf-8":
1) Started Firefox with "LC_ALL=en_US.utf-8 /usr/bin/firefox -no-remote -P nonexistent"
2) Created new profile
3) Installed NoScript
4) NoScript options->Embeddings->Apply these restrictions to whitelisted sites too: Checked box
5) Go to any site with an embedded youtube video or youtube.com itself and click on the blocked video immediately, before the popup goes away: The popup will remain until the dialog is closed.

And the easy workaround is to simply move the mouse inside the blocking box until the popup goes away and then click.

So, yes, it looks a lot like a Gnome or Firefox GUI bug.

P.S.: @GµårÐïåñ: Thanks for the security pack link. Very interesting things in there.
The productivity pack link seems dead however.

[Tom T.]

Since this is a Fx or Gnome bug, and not a NS bug, we'll mark it as Resolved. Thanks for letting us know.