Unreadable buttons in alert() and prompt() dialogs [$100]

[xverges]

On Windows XP, the alert() and prompt() windows have hardly readable buttons.
On Windows 7, it works properly.
https://groups.google.com/d/topic/node-webkit/mByrzqMeMYU/discussion

There is a $100 open bounty on this issue. Add to the bounty at Bountysource.

[ButzYung]

I can confirm similar problem on Vista as well.

[Mithgol]

Probably depends on the theme set in the system.

For example, that's the result for the classic theme on Windows XP:

Also, what's your node-webkit version? (The most recent version does not seem to display “Alert” or “Prompt” in the title of those dialog windows, as far as I see.)

[ghost]

I use node-webkit 0.4.2 and Windows 7 64bit, the screen of code like:

    window.onbeforeunload=function(event){
        return "alert";
    }

looks like this:

[ghost]

This issue still exists with latest node webkit build and windows xp. (not tested on other windows versions)...

[mattroyer]

This issue also exists with the latest node webkit build and Window 7. I am using it for a confirm dialog .

[TooBug]

Same issue (nw 0.8 + xp + confirm and alert). Any update?

[CarmelK]

Same issue on windows 7 32bit and node-webkit v0.10.1-win-ia32

[AndryBray]

Same problem with windows xp + nw 0.10.5
works well with windows 7 Home Premium instead.

[CarmelK]

It worked much better on pc when I used 'window.alert' instead of just 'alert'.

[pVesian]

Bug is still present (NW v0.10.5, Windows 7 Pro). Please note that with alert() and confirm() (same problem with window.alert() and window.confirm()):

• pressing "enter" key does not trigger anything
• clicking the closing arrow does not trigger anything

@CarmelK : Not on Win 7 Pro here.

[Mithgol]

Now that I think of that, alert and window.alert is the same thing:

Therefore there's no reason for window.alert to behave any better.

[ghost]

Just to add - this is a problem on Win7 if you disable Aero - it seems OK (at least for me) if you have Aero enabled - checked in latest version (W764 here)

[khoin]

I have the same problem here on Windows 7 Basic 32-bit. Since it's Basic, there's no Aero mode.

[pVesian]

@rogerwang Any idea what could be causing this? It's realy disturbing and dates back 2 years...

[rogerwang]

will look to fix it soon.

[yangg]

@rogerwang When would you like to look into it ?

[goshatch]

Hi guys, any news on this? :)

[sanderboom]

Quite a weird issue, and really disturbing. Any ideas?

[xueeinstein]

Just as @Mithgol said, the real problem is about the compatibility of chromium of old windows system. As you know, such basic javascript code is handled by chromium module itself.

Anyway, both alert() and prompt() dialog work well on my win7-64bit.
Suggestion: try to build nw.js locally. Maybe on different .NET version it works differently.

[ghost]

Note: it has NOTHING to do with "older systems", there are plenty of 'newer systems' which run Windows7 without Aero (some software doesn't work well with it - some hardware isn't good enough and as someone said, there are versions of W7 which don't have it!!)

I've been doing a bit of work with a similar project to nw.js - atom-shell - and I came across a comment by the developer who was explaining that all the "dialog" windows (generated by alert, confirm, prompt) have to be coded manually per-platform and that was something he wouldn't be doing because there were easy alternatives such as http://tristanedwards.me/sweetalert and http://fabien-d.github.io/alertify.js/ - more here too http://webuilddesign.com/6-javascript-tools-to-create-cool-user-alert/ ...

So I'm in the process of gutting-out all my usage of alert/prompt/confirm as I type - I like the more 'styleable' CSS approach anyway - thought I'd leave this here for anyone who runs into this in future tho

[goshatch]

While CSS-based solutions are great in most cases, in the case of our project we rely quite a bit on the blocking nature of window.confirm, so this is still very much an issue.

[ghost]

CSS-based alerts offer a variety of 'modal' options - the simplest of which
is throwing a transparent div over the whole screen which traps
clicks/keypresses and anything else a user might throw at it whilst the
dialog is shown

The only real downside to a CSS dialog (much like a CSS contextmenu or a
CSS FileSelector or whatever else you might make) is that you're locked
inside the Window (a particular problem for context menus but not really
here?)

On 13 March 2015 at 02:50, Gueorgui Tcherednitchenko <
notifications@github.com> wrote:

While CSS-based solutions are great in most cases, in the case of our
project we rely quite a bit on the blocking nature of window.confirm, so
this is still very much an issue.

—
Reply to this email directly or view it on GitHub
#433 (comment).

[mbrami76]

It's not just "Aero"... It's Win 7 presentation styles (not sure what is going to happen on winXp). By disabling them from MyComputer>Properties>Advanced>Performance will make the dialog buttons visible, but your desktop will look like Win95.

Workaround
Just disable visual styles only for your application. Get your launcher properties page, go to tab "Compatibility" and check "Disable visual styles" under "Settings" group. Labels may be different, since my OS is not in english. By doing so, only your app will run without Win7 visual styles (this will only affect window borders and titlebar).

Here's my settings and result:

[pVesian]

I'll try that. But that doesn't fix the problem for the users of my app,
does it?

2015-04-28 11:24 GMT+02:00 mbrami76 notifications@github.com:

It's not just "Aero"... It's Win 7 presentation styles (not sure what is
going to happen on winXp). By disabling them from
MyComputer>Properties>Advanced>Performance will make the dialog buttons
visible, but your desktop will look like Win95.

Workaround
Just disable visual styles only for your application. Get your launcher
properties page, go to tab "Compatibility" and check "Disable visual
styles" under "Settings" group. Labels may be different, since my OS is not
in english. By doing so, only your app will run without Win7 visual styles
(this will only affect window borders and titlebar).

—
Reply to this email directly or view it on GitHub
#433 (comment).

[mbrami76]

@pVesian for current users they should do it by themselves, or you could ship a patch with a windows registry update to permanently adopt the compatibility mode just for your application (see this for more info: http://www.verboon.info/2011/03/running-an-application-as-administrator-or-in-compatibility-mode/). Unfortunately I couldn't find any command-line switch or option to enable this, and if anyone has info on this it would be highly appreciated.

[ghost]

Suggesting people hack the registry/change system settings to make dialogs
work in one application is crazy - third-party users aren't going to be
pleased you changed their system settings and in-house applications making
such a change could affect other applications by doing so.

Using CSS-based dialogs is a better solution because it's making proper
user of the platform you're developing on - you have more control over how
things look and behave - it's a proper solution to the problem.

Also - I think nw.js needs to address this properly by either

a - fixing it
b - disabling dialogs (or at least throwing warnings at developers of the
potential issues) - that's the approach which atom-shell has taken in the
same situation

On 28 April 2015 at 16:29, mbrami76 notifications@github.com wrote:

@pVesian https://github.com/pVesian for current users they should do it
by themselves, or you could ship a patch with a windows registry update to
permanently adopt the compatibility mode just for your application (see
this for more info:
http://www.verboon.info/2011/03/running-an-application-as-administrator-or-in-compatibility-mode/
).

—
Reply to this email directly or view it on GitHub
#433 (comment).

[mbrami76]

Suggesting people hack the registry/change system settings to make dialogs
work in one application is crazy - third-party users aren't going to be
pleased you changed their system settings and in-house applications making
such a change could affect other applications by doing so.

Totally agree that this is not the way. That's why it's called a workaround. By the way changing the registry the way it is suggested it's not exactly a hack, but a normal operation: every single application you are going to install on windows quite "hacks" the registry, and such a change it is supposed not going to affect any other application, since it is application-specific.

Using CSS-based dialogs is a better solution because it's making proper
user of the platform you're developing on - you have more control over how
things look and behave - it's a proper solution to the problem.

On this I do not agree, because you are assuming that any app is consistently more robust than the platform: I don't think this is realistic. Alerts and Confirms are designed to be native to the OS (and not the application) because are supposed to be a bit more reliable and robust.

In my opinion the proper solution is to fix the issue and continue using system dialogs.

[ghost]

Just to be clear, the reason this issue exists is because those dialogs are
NOT supported/provided by Chromium (I believe?) - they have to be
implemented manually??

In nw.js there is this issue and it's been there a LONG time - in
atom-shell they've simply not bothered doing it (trying to use them just
throws an error message!)

I'm not entirely sure a browser should be throwing 'OS-style' dialogs at a
user OTHER than the file browser (it's the ONLY OS-native action a person
does within a web-based app) - making everything else 'CSS/HTML/JS'
actually makes a degree of sense because it's consistent across all
platforms

Whatever tho, this bug had been around for a long time - may be around for
longer and even if it's fixed, there's nothing to say similar bugs won't
creep back in future so the wise choice is one which is a permanent fix
surely?

On 28 April 2015 at 21:30, mbrami76 notifications@github.com wrote:

Suggesting people hack the registry/change system settings to make dialogs
work in one application is crazy - third-party users aren't going to be
pleased you changed their system settings and in-house applications making
such a change could affect other applications by doing so.

Totally agree that this is not the way. That's why it's called a
workaround. By the way changing the registry the way it is suggested it's
not exactly a hack, but a normal operation: every single application you
are going to install on windows quite "hacks" the registry, and such a
change it is supposed not going to affect any other application, since
it is application-specific.

Using CSS-based dialogs is a better solution because it's making proper
user of the platform you're developing on - you have more control over how
things look and behave - it's a proper solution to the problem.

On this I do not agree, because you are assuming that any app is
consistently more robust than the platform: I don't think this is
realistic. Alerts and Confirms are designed to be native to the OS (and not
the application) because are supposed to be a bit more reliable and robust.

In my opinion the proper solution is to fix the issue and continue
using system dialogs.

—
Reply to this email directly or view it on GitHub
#433 (comment).

[rogerwang]

It will be fixed in the upcoming nw13 version.

[TateHuang]

nw13 not support NPAPI,while nw12 is still with this bug...this is really disturbing

[rogerwang]

Close as it's fixed in nw13.

@TateHuang how is NPAPI related to the alert dialog?