function call location?

Dr J R Stockton · Oct 20, 2011

Within a function body, and without using any of the arguments provided
in the call of the function, can the function obtain a reference to the
script element from within which it was called, and if so how? The
script element containing the definition of the function is of no
interest.

Antony Scriven · Oct 21, 2011

Within a function body, and without using any of the
arguments provided in the call of the function, can the
function obtain a reference to the script element from
within which it was called, and if so how? The script
element containing the definition of the function is of
no interest.

In Firefox, for example, you might be able to do something
with e.stack:

<html>
<body>
<script id="foo">
var f = function(){
try{
qwoazlskjfalksdtjo4tjwf();
}catch(e){
alert(e.stack);
alert(window.documentElement.innerHTML);
}
};
</script
<script id="bar">
f();
</script>
</body>
</html>

What's your goal? --Antony

Dr J R Stockton · Oct 22, 2011

In comp.lang.javascript message <20ecde0b-c4e3-44df-9e34-a447753b0fb9@g1
6g2000yqa.googlegroups.com>, Thu, 20 Oct 2011 17:13:28, Antony Scriven

In Firefox, for example, you might be able to do something
with e.stack:

<html>
<body>
<script id="foo">
var f = function(){
try{
qwoazlskjfalksdtjo4tjwf();
}catch(e){
alert(e.stack);
alert(window.documentElement.innerHTML);
}
};
</script
<script id="bar">
f();
</script>
</body>
</html>

As posted, that shows f(); in the window in FF 7.0.1 Win XP sp3.
After the obvious repair, it gives the first alert, then the error
message
Error: window.documentElement is undefined
Source File: file:///C:/HOMEPAGE/$1.htm Line: 10

What's your goal? --Antony

The alert routine always used to pop up s simple dialogue, which could
be dragged around. Except for Opera, it was alas in the small font used
by Windows for the main menu bar. The page issuing the alert was
unchanged, apart from having lost focus.

A few updates ago, Opera changed to giving a non-standard but still
draggable alert dialogue, and greying the page into near unreadability -
which is bad if the alert is reporting details of an input error as is
commonly the case. It retained the more readable font. My easy fix was
to not use Opera for such pages.

Since my most recent Firefox upgrade, from 3.6.23 to 7.0.1, FF's alert
is like opera's, except that it is not draggable (so may cover what one
wants to read) and uses the hard-to-read font.

My Web site has, counting with MiniTrue, 566 calls of alert.

So I was thinking of replacing window.alert with another function Alert
or by editing replace calls of alert with ones of Alert by editing the
source (with MiniTrue). The new function Alert would insert a suitable
box somewhere on the page. In practice, inserting before or after the
script element could be a good default (a second argument, if provided,
would choose a location). Alternatively, the function Alert could open
a new window.

The same would apply to window.confirm and window.prompt.

<FAQENTRY> replacement for alert confirm prompt </FAQENTRY>

Scott Sauyet · Oct 23, 2011

Dr said:
[ ... alert boxes problematic ... ]
My Web site has, counting with MiniTrue, 566 calls of alert.

So I was thinking of replacing window.alert with another function Alert
or by editing replace calls of alert with ones of Alert by editing the
source (with MiniTrue). The new function Alert would insert a suitable
box somewhere on the page. In practice, inserting before or after the
script element could be a good default (a second argument, if provided,
would choose a location). Alternatively, the function Alert could open
a new window.

The same would apply to window.confirm and window.prompt.

Why would it matter where in the markup the box was placed?
Presumably you would want this to sit in a higher z-index than the
surrounding content, so wouldn't simply placing this with
position:absolute (and allowing whatever drag options you choose) be a
sensible alternative. Then the box could be placed in an arbitrary
spot in the markup. (For such things, I usually simply append to the
end of the BODY.)

There are numerous libraries available to add dialogs to web pages.
Can you simply use one of them?

As the the original question, I rather doubt there would be any clean
way to do this, but by throwing and catching an exception, you might
be able to track the calling function to its URL and line number in
some browsers.

-- Scott

Antony Scriven · Oct 24, 2011

Line: 10

Sorry, I seem to have had a bit of an editing nightmare with
that article. That should be document.documentElement.

What's your goal? --Antony

Click to expand...

[...]

So I was thinking of replacing window.alert with
another function Alert or by editing replace calls of
alert with ones of Alert by editing the source (with
MiniTrue). The new function Alert would insert
a suitable box somewhere on the page. In practice,
inserting before or after the script element could be
a good default (a second argument, if provided, would
choose a location). Alternatively, the function Alert
could open a new window.

[...]

Click to expand...

As Scott already said, why does it need to go near the
script element? --Antony

Dr J R Stockton · Oct 24, 2011

In comp.lang.javascript message <d29d6f09-972a-4e45-85a9-85d2c052da38@hj
4g2000vbb.googlegroups.com>, Sun, 23 Oct 2011 10:00:18, Scott Sauyet

Dr said:
Dr said:

[ ... alert boxes problematic ... ]
My Web site has, counting with MiniTrue, 566 calls of alert.

So I was thinking of replacing window.alert with another function Alert
or by editing replace calls of alert with ones of Alert by editing the
source (with MiniTrue). The new function Alert would insert a suitable
box somewhere on the page. In practice, inserting before or after the
script element could be a good default (a second argument, if provided,
would choose a location). Alternatively, the function Alert could open
a new window.

The same would apply to window.confirm and window.prompt.

Click to expand...

Why would it matter where in the markup the box was placed?

For my pages, that would in general put it near, but not on, the cause
of the Alert, which would be a good start.

Presumably you would want this to sit in a higher z-index than the
surrounding content, so wouldn't simply placing this with
position:absolute (and allowing whatever drag options you choose) be a
sensible alternative.

It would. Remember that the most effective way of finding a good
solution is to present a possible solution in a Usenet newsgroup. I'd
never given any thought to z-index until last week, when I wanted
(because of another nasty in Firefox 7) to put a large outline - the
border of an empty div - on a page, position absolute. That's OK, and
it was transparent; but it masked clicks on what was showing through,
and z-index fixed that. However, ISTM that now I'd have to discover the
Y-position to give it.

Then the box could be placed in an arbitrary
spot in the markup. (For such things, I usually simply append to the
end of the BODY.)

There are numerous libraries available to add dialogs to web pages.
Can you simply use one of them?

It will take me longer to find and understand a sound one than to
implement an acceptable solution using a well-placed and initially non-
displayed div element, accessed by getElementById.

As the the original question, I rather doubt there would be any clean
way to do this, but by throwing and catching an exception, you might
be able to track the calling function to its URL and line number in
some browsers.

Must be all likely GUI browsers, at least.

Scott Sauyet · Oct 25, 2011

Dr said:
Scott Sauyet posted:

Presumably you would want this to sit in a higher z-index than the
surrounding content, so wouldn't simply placing this with
position:absolute (and allowing whatever drag options you choose) be a
sensible alternative.

Click to expand...

It would. Remember that the most effective way of finding a good
solution is to present a possible solution in a Usenet newsgroup.
[ ... ]

There are numerous libraries available to add dialogs to web pages.
Can you simply use one of them?

Click to expand...

It will take me longer to find and understand a sound one than to
implement an acceptable solution using a well-placed and initially non-
displayed div element, accessed by getElementById.

Ok, but welcome to the world of web-scripting. What once seem to be
acceptable solutions often turn out to be less than acceptable as
reports from the wild world of the web pour in.

Must be all likely GUI browsers, at least.

As I said, I doubt there's a real solution to this.

Good luck,

-- Scott

Dr J R Stockton · Oct 25, 2011

In comp.lang.javascript message <8fa806c9-a274-4ca7-b6be-8d6235d2f7ae@s1
4g2000vbj.googlegroups.com>, Mon, 24 Oct 2011 02:11:46, Antony Scriven

As Scott already said, why does it need to go near the
script element? --Antony

Because that, as a default, will in my pages usually be near enough
where I would choose to have it appear. Then, only where that is not
near enough will I need to indicate a specific location.

Scott Sauyet · Oct 26, 2011

Dr said:
Antony Scriven posted:

Because that, as a default, will in my pages usually be near enough
where I would choose to have it appear. Then, only where that is not
near enough will I need to indicate a specific location.

I had been trying to point out, though, that mark-up proximity need
have no bearing on visible proximity.

What would you expect if the alert was called from a script running in
the HEAD?

-- Scott

Dr J R Stockton · Oct 26, 2011

In comp.lang.javascript message <0d36dd0b-5638-44d2-9102-f88fffbe44fc@f3
6g2000vbm.googlegroups.com>, Tue, 25 Oct 2011 05:13:05, Scott Sauyet

Dr J R Stockton wrote:

Ok, but welcome to the world of web-scripting. What once seem to be
acceptable solutions often turn out to be less than acceptable as
reports from the wild world of the web pour in.

It's always nice to hear from an actual reader with a good suggestion
that can easily be implemented.

The best thing would be for browser writers to see sense, and make the
alert function do the same, and correct, thing in all browsers.

In IE 8, Firefox 3, Safari 5.1.1, Chrome 14 & 15, function alert does
the right thing - a draggable box that holds focus with respect to the
issuing page.

In Firefox 7 and Opera 11.52, the page is greyed, which is very bad;
in FF7, the alert cannot even be dragged.

In Opera 11.52, one can copy from the text shown, which is good; and the
text is larger, also good.

I don't think any of them allow the text to be zoomed, as obviously they
ought. I don't think any allow font selection (an alert may want fixed
pitch). I don't think any are good at identifying, in words, the
browser and the page.

Fancy alerts are acceptable, if they are a new and not a substitute
feature and have a new name.

FYI - Chrome is now 15.0.

Dr J R Stockton · Oct 27, 2011

In comp.lang.javascript message <67d427d7-f6c3-4e54-9a64-af58f667094f@u3
5g2000yqb.googlegroups.com>, Wed, 26 Oct 2011 05:09:29, Scott Sauyet

I had been trying to point out, though, that mark-up proximity need
have no bearing on visible proximity.

What would you expect if the alert was called from a script running in
the HEAD?

You missed the bit "in my pages". Because I like to have scripts in the
source adjacent to the forms that use them, the scripts in the heads (if
any) (and in include files) rarely contain specific material such as
alerts (apart from warnings issued as a result of browser testing, which
apply page-wide). You also missed "as a default"; I have always
intended to provide a possible second argument giving the exact
location, as an ID string or an element reference.

I would not expect; I would test. It might be OK, but does not need to
be.

General : FYI :
CSS : .TWO { border-bottom: 0.6ex double black; }
HTML : <span class=TWO>Maths result</span>
gives a nice text-scaled double underline, as I was taught to use in
school.

Antony Scriven · Oct 28, 2011

Dr said:
[...] Scott Sauyet [...] posted:

Dr said:

Antony Scriven posted:
As Scott already said, why does it [a custom alert
dialog] need to go near the script element?
Because that, as a default, will in my pages usually
be near enough where I would choose to have it
appear. Then, only where that is not near enough
will I need to indicate a specific location.

Click to expand...

Click to expand...

I had been trying to point out, though, that mark-up
proximity need have no bearing on visible proximity.

Click to expand...

What would you expect if the alert was called from
a script running in the HEAD?

Click to expand...

You missed the bit "in my pages". Because I like to have
scripts in the source adjacent to the forms that use
them, the scripts in the heads (if any) (and in include
files) rarely contain specific material such as alerts
(apart from warnings issued as a result of browser
testing, which apply page-wide). You also missed "as
a default"; I have always intended to provide a possible
second argument giving the exact location, as an ID
string or an element reference.

I would not expect; I would test. It might be OK, but
does not need to be.

So why wouldn't the middle of the viewport be a good
default? It doesn't matter a great deal where you insert the
alert div in that case.

General : FYI :
CSS : .TWO { border-bottom: 0.6ex double black; }
HTML : <span class=TWO>Maths result</span>
gives a nice text-scaled double underline, as I was taught to use in
school.

Huh? --Antony

Dr J R Stockton · Oct 29, 2011

In comp.lang.javascript message <9416d51e-7b70-45f9-a849-817adacc04e3@t8
g2000yql.googlegroups.com>, Thu, 27 Oct 2011 17:25:21, Antony Scriven

On Oct 27, 7:27 pm, Dr J R Stockton wrote:

So why wouldn't the middle of the viewport be a good
default? It doesn't matter a great deal where you insert the
alert div in that case.

There, it may well obstruct the part of the page that one wants to see
at the same time. Remember, I am the author of my pages; I have read
them all; and it is for me to choose my authoring preferences.

But if you can provide a set of functions, not unreasonably long, that
gives in all browsers substantially (font apart) what window.alert
traditionally gives, then I shall use it.

Huh? --Antony

If you don't understand, you don't need to understand. It is a work-
round for the lack, in HTML, of <uu>, and the corresponding lack in
CSS2.

I Need Help with making a function that draws in a canvas using location data.	1	Dec 17, 2021
Tasks	1	Nov 29, 2022
Graph of quadratic function with CanvasRenderingContext2D	2	May 9, 2024
Why doesn't the function get called?	1	Nov 20, 2023
How do I call the exact function on page load?	6	May 19, 2023
Ajax function only returns error and does not call php function	2	Aug 6, 2022
How can I guarantee that the all callback functions of the first Ajax API call have finished executing before initiating the 2 call in JavaScript?	2	Oct 30, 2023
Help with a function	8	Mar 11, 2020

function call location?

Dr J R Stockton

Antony Scriven

Dr J R Stockton

Scott Sauyet

Antony Scriven

Dr J R Stockton

Scott Sauyet

Dr J R Stockton

Scott Sauyet

Dr J R Stockton

Dr J R Stockton

Antony Scriven

Dr J R Stockton

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads