Huge tooltip prevents noscript operation / browsing

[anystupidassname]

This pretty much only happens on youtube but it has been a pain for years. I've been too lazy to post about it. Now that I'm trying to get a good screenshot it doesn't look as bad of course, but usually the tooltip is bigger and makes it almost completely impossible to get access to the OK button. You have to grab the window title under it and drag the window over somewhere in such a way to get the OK button out from under the tooltip. Basically, I'm asking if you can restrict tooltips size and/or disable tooltips on just a particular domain maybe?!? I don't want to disable tooltips entirely since I find them useful in all other scenarios.

If I'm just stupid and missing something, my bad, can somebody please enlighten me? Thanks!

http://i.imgur.com/h8V5g.png
http://i.imgur.com/51dZ4.png
http://i.imgur.com/CySdE.png

[therube]

You should only see that while you hover (momentarily too) the object.
Once you click the object, it should disappear.
At that point, you are interacting with the NoScript dialog - (a modal dialog, hence) which you must either accept or dismiss before any further actions are allowed.

Not sure how you're managing to get the two together?

http://www.youtube.com/watch?v=bVt46tZLhtA


Maybe something in the noscript.hoverUI.* Preferences (about:config) ?

[Giorgio Maone]

@therube:
Notice he's on Ubuntu, it might be a GNOME bug...
As you said, the tooltip should go away as soon as any interaction happens, and it shouldn't obstruct clicks anyway.

[LucidOK]

Can't reproduce in Lucid, updated today. Tested on youtube with various pages (not that easy to find anything *not* youtube these days )
The tooltip slides out of the way when NS placeholder is selected with the mouse.

[LucidOK]

Forgot to add:
Test done with clean default profile.
But that Gnome panel is very very buggy, and tooltips in general don't behave predictably there, let alone in Fx.
In particular, with any UI enhancements, found in Prefs>Appearance|Visual effects, tooltips get unpredictable and many turn them off.
A couple older similar launchpad bugs I found if you want to report yours:
https://bugs.launchpad.net/ubuntu/+sour ... bug/131556
https://bugs.launchpad.net/ubuntu/+sour ... bug/239462

[LucidOK]

Final thought for workaround:
ESC should get rid of the tooltip in this case of several different controls on the page, but no guarantees that Gnome will behave nicely

[anystupidassname]

Thanks for pointing me towards the Gnome bug. I've been meaning to try Gnome 3 anyway, so I guess this is a good excuse.

Perhaps I should clarify that, regardless of the reason for the tooltip staying up, I would consider it more logical for there to be a character limit to the tooltips. Better yet, an adjustable parameter. Perhaps one of these types of things: "Beginning of the sen...nd the end of the sentence"? Is this something that is possible in Noscript? Does ANYbody read more than 2 lines all the way across their screens in a tooltip?!?

[Giorgio Maone]

Worked around in latest development build.

[RainerBlome]

Hi, please make it possible to revert to the old tooltip behavior with the full URL.

The full disclosure of the blocked URL in the placeholder tooltip makes for more transparency.
It gives the user a visual idea of the amount and type of information that would be sent to the server.
A huge tooltip clearly shows that an unusually large amount of information is sent, probably much more than is needed to just fulfill the request.
This in turn is an indication that the users' privacy is more at risk with such a site.

A configuration parameter to reenable the old behavior would be enough.

[al_9x]

NS should not lose functionality for the sake of working around bugs in certain platforms. I never had any issues with tooltips and would like to see full urls. For example, I couldn't understand why a particular iframe was not allowed after placeholder activation and a refresh. Turns out its url was changing but the tooltip was not showing the change due to truncation. No doubt there are other reasons, such as the one mentioned in the previous post.

[Giorgio Maone]

Please check latest development build.

[al_9x]

Please check latest development build.

back to normal, thanks.

[RainerBlome]

Works as expected. The parameter's default value is "full URL" ("true"), which I like.
For a switch of the parameter value to take effect, for example to "short URL" ("false"), a reload of the affected page is required, which is fine.
Thanks!