Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #31275 > unrolled thread

restore window alert

Back to article view | Back to comp.lang.javascript

Contents

  restore window alert Andrew Poulos <ap_prog@hotmail.com> - 2016-09-08 10:39 +1000
    Re: restore window alert "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-07 18:00 -0700
    Re: restore window alert JJ <jj4public@vfemail.net> - 2016-09-08 18:47 +0700
      Re: restore window alert "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-08 06:43 -0700
        Re: restore window alert Martin Honnen <martin.honnen@gmx.de> - 2016-09-08 16:32 +0200
          Re: restore window alert Andrew Poulos <ap_prog@hotmail.com> - 2016-09-09 14:49 +1000
            Re: restore window alert "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-09-09 06:20 -0700
        Re: restore window alert Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-10 16:26 +0200
          Re: restore window alert Ram Tobolski <ramtob@gmail.com> - 2016-09-11 00:17 -0700
            Re: restore window alert Andrew Poulos <ap_prog@hotmail.com> - 2016-09-11 17:57 +1000
            Re: restore window alert Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-11 11:19 +0200
          Re: restore window alert Andrew Poulos <ap_prog@hotmail.com> - 2016-09-11 19:00 +1000
            Re: restore window alert Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-11 13:24 +0200

#31275 — restore window alert

A third party elearning output I'm required to modify has, in a giant 
JavaScript file, overridden window.alert. The original value for 
window.alert has not been stored.

I cannot modify the JavaScript file directly (each time the elearning is 
published it recreates the file with whatever it deems necessary) so I 
have to add a new file.

Any custom JavaScript I add can only go after their JavaScript.

Is there any way to reference the native window.alert once its been 
overridden?

Andrew Poulos

[toc] | [next] | [standalone]

#31276

On Wednesday, September 7, 2016 at 7:39:31 PM UTC-5, Andrew Poulos wrote:
> A third party elearning output I'm required to modify has, in a giant 
> JavaScript file, overridden window.alert. The original value for 
> window.alert has not been stored.
> 
> I cannot modify the JavaScript file directly (each time the elearning is 
> published it recreates the file with whatever it deems necessary) so I 
> have to add a new file.
> 
> Any custom JavaScript I add can only go after their JavaScript.
> 
> Is there any way to reference the native window.alert once its been 
> overridden?

You can create an iframe and use the alert of that frame's contentWindow

[toc] | [prev] | [next] | [standalone]

#31277

On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
> A third party elearning output I'm required to modify has, in a giant 
> JavaScript file, overridden window.alert. The original value for 
> window.alert has not been stored.
> 
> I cannot modify the JavaScript file directly (each time the elearning is 
> published it recreates the file with whatever it deems necessary) so I 
> have to add a new file.
> 
> Any custom JavaScript I add can only go after their JavaScript.
> 
> Is there any way to reference the native window.alert once its been 
> overridden?
> 
> Andrew Poulos

Use:

  window.constructor.prototype.alert

e.g.:

  window.constructor.prototype.alert.call(window, "the message");

or restore it as a different name for easy access later e.g.:

  window.alert2 = window.constructor.prototype.alert;
  window.alert2("the message");

[toc] | [prev] | [next] | [standalone]

#31279

On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
> > A third party elearning output I'm required to modify has, in a giant 
> > JavaScript file, overridden window.alert. The original value for 
> > window.alert has not been stored.
> > 
> > I cannot modify the JavaScript file directly (each time the elearning is 
> > published it recreates the file with whatever it deems necessary) so I 
> > have to add a new file.
> > 
> > Any custom JavaScript I add can only go after their JavaScript.
> > 
> > Is there any way to reference the native window.alert once its been 
> > overridden?
> > 
> > Andrew Poulos
> 
> Use:
> 
>   window.constructor.prototype.alert
> 
> e.g.:
> 
>   window.constructor.prototype.alert.call(window, "the message");
> 
> or restore it as a different name for easy access later e.g.:
> 
>   window.alert2 = window.constructor.prototype.alert;
>   window.alert2("the message");


I like this solution better than mine, but I'm paranoid about using "window.constructor". I see it in my mind as: 
[host object].constructor

Is this "safe" to us like this?

[toc] | [prev] | [next] | [standalone]

#31280

On 08.09.2016 15:43, Michael Haufe (TNO) wrote:
> On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
>> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:

>>> Is there any way to reference the native window.alert once its been
>>> overridden?

>> Use:
>>
>>   window.constructor.prototype.alert
>>
>> e.g.:
>>
>>   window.constructor.prototype.alert.call(window, "the message");
>>
>> or restore it as a different name for easy access later e.g.:
>>
>>   window.alert2 = window.constructor.prototype.alert;
>>   window.alert2("the message");
>
>
> I like this solution better than mine, but I'm paranoid about using "window.constructor". I see it in my mind as:
> [host object].constructor
>
> Is this "safe" to us like this?

For me on Windows 10 the alert only appears with Internet Explorer in 
https://jsfiddle.net/apawxx0m/, Edge, Chrome and Firefox show a script 
error in the console .

[toc] | [prev] | [next] | [standalone]

#31282

On 9/09/2016 12:32 AM, Martin Honnen wrote:
> On 08.09.2016 15:43, Michael Haufe (TNO) wrote:
>> On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
>>> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
>
>>>> Is there any way to reference the native window.alert once its been
>>>> overridden?
>
>>> Use:
>>>
>>>   window.constructor.prototype.alert
>>>
>>> e.g.:
>>>
>>>   window.constructor.prototype.alert.call(window, "the message");
>>>
>>> or restore it as a different name for easy access later e.g.:
>>>
>>>   window.alert2 = window.constructor.prototype.alert;
>>>   window.alert2("the message");
>>
>>
>> I like this solution better than mine, but I'm paranoid about using
>> "window.constructor". I see it in my mind as:
>> [host object].constructor
>>
>> Is this "safe" to us like this?
>
> For me on Windows 10 the alert only appears with Internet Explorer in
> https://jsfiddle.net/apawxx0m/, Edge, Chrome and Firefox show a script
> error in the console .

In Chrome I get
Uncaught TypeError: Cannot read property 'call' of undefined

In Firefox I get
TypeError: window.constructor.prototype.alert is undefined

In Edge I get
Unable to get property 'call' of undefined or null reference

:-(

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#31283

On Thursday, September 8, 2016 at 11:49:20 PM UTC-5, Andrew Poulos wrote:
> On 9/09/2016 12:32 AM, Martin Honnen wrote:
> > On 08.09.2016 15:43, Michael Haufe (TNO) wrote:
> >> On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
> >>> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
> >
> >>>> Is there any way to reference the native window.alert once its been
> >>>> overridden?
> >
> >>> Use:
> >>>
> >>>   window.constructor.prototype.alert
> >>>
> >>> e.g.:
> >>>
> >>>   window.constructor.prototype.alert.call(window, "the message");
> >>>
> >>> or restore it as a different name for easy access later e.g.:
> >>>
> >>>   window.alert2 = window.constructor.prototype.alert;
> >>>   window.alert2("the message");
> >>
> >>
> >> I like this solution better than mine, but I'm paranoid about using
> >> "window.constructor". I see it in my mind as:
> >> [host object].constructor
> >>
> >> Is this "safe" to us like this?
> >
> > For me on Windows 10 the alert only appears with Internet Explorer in
> > https://jsfiddle.net/apawxx0m/, Edge, Chrome and Firefox show a script
> > error in the console .
> 
> In Chrome I get
> Uncaught TypeError: Cannot read property 'call' of undefined
> 
> In Firefox I get
> TypeError: window.constructor.prototype.alert is undefined
> 
> In Edge I get
> Unable to get property 'call' of undefined or null reference
> 
> :-(

Back to the iframe I'd say...

[toc] | [prev] | [next] | [standalone]

#31302

Michael Haufe (TNO) wrote:

> On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
>> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
>> > Is there any way to reference the native window.alert once its been
>> > overridden?
>> 
>> Use:
>> 
>>   window.constructor.prototype.alert
>> 
>> e.g.:
>> 
>>   window.constructor.prototype.alert.call(window, "the message");
>> 
>> or restore it as a different name for easy access later e.g.:
>> 
>>   window.alert2 = window.constructor.prototype.alert;
>>   window.alert2("the message");
> 
> […] I'm paranoid about using "window.constructor". I see it in my mind as:
> [host object].constructor

ACK.  Also, this is a long-winded, error-prone way of writing 
Object.getPrototypeOf(window) [formerly, window.__proto__ in some DOM 
implementations].
 
> Is this "safe" to us like this?

No.  The safest approach is to create a Window object and copy the value of 
its “alert” property.

An iframe, as you suggested, does not suffice, though, because that only 
gives you the “iframe” element object.  Accessing the window object of the 
iframe document requires either support for the “contentWindow” property of 
the iframe object or for the “contentDocument” of the iframe object and the 
“defaultView” property of the iframe’s document object.

As an alternative, a new window object can be created, the reference to its 
“alert” method retrieved, and its close() method be called:

  var w = window.open();
  var _alert = w.alert;
  w.close();
  
Then either

  window.alert = _alert;
  window.alert(42);

or

  Function.prototype.call.call(_alert, window, 42);

  (AFAIK, all host methods can be safely .call()ed this way, and with 
   combinations of .call() and .apply().)

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#31315

On Saturday, September 10, 2016 at 5:26:30 PM UTC+3, Thomas 'PointedEars' Lahn wrote:

>   var w = window.open();
>   var _alert = w.alert;
>   w.close();
>   

This does not seem practical. First, it will actually open a redundant new browser window, or tab. Second, the close() method will not work, but will raise a cross-origin error (current window and new window will have different origins).

[toc] | [prev] | [next] | [standalone]

#31316

On 11/09/2016 5:17 PM, Ram Tobolski wrote:
> On Saturday, September 10, 2016 at 5:26:30 PM UTC+3, Thomas
> 'PointedEars' Lahn wrote:
>
>> var w = window.open(); var _alert = w.alert; w.close();
>>
>
> This does not seem practical. First, it will actually open a
> redundant new browser window, or tab. Second, the close() method will
> not work, but will raise a cross-origin error (current window and new
> window will have different origins).

I use window.open together with close() "all the time" and I've yet to 
encounter a CO error.

My concern is that popup blockers may stop the window from opening.

I need to get the native alert and if having a window flash up is the 
"only" way then I may just have to live with it.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#31318

Ram Tobolski wrote:

> On Saturday, September 10, 2016 at 5:26:30 PM UTC+3, Thomas 'PointedEars'
> Lahn wrote:
>>   var w = window.open();
>>   var _alert = w.alert;
>>   w.close();
>>   
> 
> This does not seem practical. First, it will actually open a redundant new
> browser window, or tab. Second, the close() method will not work, but will
> raise a cross-origin error (current window and new window will have
> different origins).

Nonsense.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#31317

On 11/09/2016 12:26 AM, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
>> On Thursday, September 8, 2016 at 6:47:29 AM UTC-5, JJ wrote:
>>> On Thu, 8 Sep 2016 10:39:16 +1000, Andrew Poulos wrote:
>>>> Is there any way to reference the native window.alert once its been
>>>> overridden?
>>>
>>> Use:
>>>
>>>   window.constructor.prototype.alert
>>>
>>> e.g.:
>>>
>>>   window.constructor.prototype.alert.call(window, "the message");
>>>
>>> or restore it as a different name for easy access later e.g.:
>>>
>>>   window.alert2 = window.constructor.prototype.alert;
>>>   window.alert2("the message");
>>
>> […] I'm paranoid about using "window.constructor". I see it in my mind as:
>> [host object].constructor
>
> ACK.  Also, this is a long-winded, error-prone way of writing
> Object.getPrototypeOf(window) [formerly, window.__proto__ in some DOM
> implementations].
>
>> Is this "safe" to us like this?
>
> No.  The safest approach is to create a Window object and copy the value of
> its “alert” property.
>
> An iframe, as you suggested, does not suffice, though, because that only
> gives you the “iframe” element object.  Accessing the window object of the
> iframe document requires either support for the “contentWindow” property of
> the iframe object or for the “contentDocument” of the iframe object and the
> “defaultView” property of the iframe’s document object.
>
> As an alternative, a new window object can be created, the reference to its
> “alert” method retrieved, and its close() method be called:
>
>   var w = window.open();
>   var _alert = w.alert;
>   w.close();
>
> Then either
>
>   window.alert = _alert;
>   window.alert(42);
>
> or
>
>   Function.prototype.call.call(_alert, window, 42);
>
>   (AFAIK, all host methods can be safely .call()ed this way, and with
>    combinations of .call() and .apply().)

This in Edge when run locally

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Alert</title>
<script type="text/javascript">
var _alert

function show() {
   var w = window.open();
   _alert = w.alert;
   w.close();

   window.setTimeout(function() {
     window.alert = _alert;
     window.alert(42);
   }, 300);
}
</script>
</head>
<body>
<p onclick="show()">Hey</p>
</body>
</html>

results in a new tab being opened and closed but no alert box appearing.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#31320

Andrew Poulos wrote:

> This in Edge when run locally
> 
> <!DOCTYPE html>
> <html>
> <head>
> <meta charset="utf-8">
> <title>Alert</title>
> <script type="text/javascript">
> var _alert
> 
> function show() {
>    var w = window.open();
>    _alert = w.alert;
>    w.close();
> 
>    window.setTimeout(function() {
>      window.alert = _alert;
>      window.alert(42);
>    }, 300);
> }
> </script>
> </head>
> <body>
> <p onclick="show()">Hey</p>
> </body>
> </html>
> 
> results in a new tab being opened and closed but no alert box appearing.

Different problem; I did not say “window.setTimeout”.  Also, you want to use 
the module pattern.

But Edge 25.10586.0.0 on Windows 10 Enterprise Evaluation, Version 1511, 
Build 10586.164, at least does have the problem that you cannot call the 
transferred “alert” method: you get “Invalid calling object” when you try.  

Internet Explorer 11.162.10586.0 behaves differently there: Depending on 
whether you close the popup before calling its alert() or afterwards, you 
get either “Invalid calling object” or “Function expected” or nothing.  I 
might look into this further when I am back in the office: debugging Edge/IE 
11 on Windows 10 in VirtualBox on OS X via TeamViewer is a PITA.

For now, something along the lines of

  var iframe, w, d, b;
  var _alert = (typeof document.createElement != "undefined")
    && (iframe = document.createElement("iframe"))
    && (iframe.style.display = "none")
    && (b = document.body)
    && (typeof b.appendChild != "undefined")
    && (b.appendChild(iframe) || true)
    && ((w = iframe.contentWindow) && w.alert
        || (d = iframe.contentDocument)
            && (w = d.defaultView)
            && w.alert))
    || (function () {
         var w = window.open("", "w" + new Date().getTime(),
                             "width=1,height=1");
         if (!w) return null;

         var local_alert = w.alert;

         w.close();

         return local_alert;
       }());

  if (_alert)
  {
    window.alert = _alert;
    window.alert(42);
    b && b.removeChild(iframe);
  }

is probably the safest bet.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web