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

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

Detect Browser full screen Or window.open

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

Contents

  Detect Browser full screen Or window.open Andrew Poulos <ap_prog@hotmail.com> - 2014-06-24 13:16 +1000
    Re: Detect Browser full screen Or window.open "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-06-24 10:26 +0200
      Re: Detect Browser full screen Or window.open Andrew Poulos <ap_prog@hotmail.com> - 2014-06-24 18:48 +1000
        Re: Detect Browser full screen Or window.open "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-06-24 11:05 +0200
    Detect Browser full screen Or window.opener (was: Detect Browser full screen Or window.open) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-24 12:48 +0200
      Re: Detect Browser full screen Or window.opener Andrew Poulos <ap_prog@hotmail.com> - 2014-06-25 07:35 +1000
        Re: Detect Browser full screen Or window.opener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-24 23:45 +0200
          Re: Detect Browser full screen Or window.opener Andrew Poulos <ap_prog@hotmail.com> - 2014-06-25 08:44 +1000
            Re: Detect Browser full screen Or window.opener Robert Heller <heller@deepsoft.com> - 2014-06-24 18:06 -0500
            Re: Detect Browser full screen Or window.opener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-25 08:02 +0200

#24985 — Detect Browser full screen Or window.open

It seems that window.open returns undefined (at least with Chrome on 
iOS) so I can't get an elearning lesson to send data to the opener page 
that communicates with the learning management system (LMS).

Given that iOS currently displays all web pages full screen, an option 
for me would be to (rather than open the lesson in a new window) to 
create an iframe (in the page that communicates with the LMS) and to 
open the lesson in it. Then the lesson can send data to top which 
communicates with the LMS.

My problem now is, how can I reliably tell either if window.open will 
not "work" or if the browser is always full screen?

Should I open a dummy page and wait for a few seconds to see if it talks 
to the opener? If it does then close the dummy page and open the lesson 
in a new window. If it doesn't then close the dummy page and open the 
lesson in an iframe.

Andrew Poulos

[toc] | [next] | [standalone]

#24987

Andrew Poulos <ap_prog@hotmail.com> wrote on 24 jun 2014 in 
comp.lang.javascript:

> It seems that window.open returns undefined (at least with Chrome on 
> iOS)

Not true in G-Chrome, don't know about the other, and the at leasts.

> Given that iOS currently displays all web pages full screen

Don't give me that, even if I won't buy that. 

"Currently" iOS doesn't display a thing here, it's switched off.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#24990

On 24/06/2014 6:26 PM, Evertjan. wrote:
> Andrew Poulos <ap_prog@hotmail.com> wrote on 24 jun 2014 in
> comp.lang.javascript:
>
>> It seems that window.open returns undefined (at least with Chrome on
>> iOS)
>
> Not true in G-Chrome, don't know about the other, and the at leasts.

Dang, I meant window.opener.

>> Given that iOS currently displays all web pages full screen
>
> Don't give me that, even if I won't buy that.
>
> "Currently" iOS doesn't display a thing here, it's switched off.

Oh, I normally watch my iOS device when its turned on and I didn't 
realise that other people watched theirs while its off.

Andrew Poulos

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

#24992

Andrew Poulos <ap_prog@hotmail.com> wrote on 24 jun 2014 in 
comp.lang.javascript:

> On 24/06/2014 6:26 PM, Evertjan. wrote:
>> Andrew Poulos <ap_prog@hotmail.com> wrote on 24 jun 2014 in
>> comp.lang.javascript:
>>
>>> It seems that window.open returns undefined (at least with Chrome on
>>> iOS)

Sorry, I read "and" for your "on".

>> Not true in G-Chrome, don't know about the other, and the at leasts.
> 
> Dang, I meant window.opener.

Okay.

>>> Given that iOS currently displays all web pages full screen
>>
>> Don't give me that, even if I won't buy that.

Chrome dos not display full screen by default on my old MacBook,
even if switched on.

>> "Currently" iOS doesn't display a thing here, it's switched off.
> 
> Oh, I normally watch my iOS device when its turned on and I didn't 
> realise that other people watched theirs while its off.

Currently I use W8.1 desktop, and android when mobile.
That Apple stuff only in an emergency.

=======================

But I can understand that in a small screen mobile situation, 
only the active window may be active, 
so you perhaps cannot connect to a [temporarily] dead parent.

If so, being an (i)frame child seems a godsent.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#24999 — Detect Browser full screen Or window.opener (was: Detect Browser full screen Or window.open)

Andrew Poulos wrote:

> It seems that [window.opener] [yields] undefined (at least with Chrome on
> iOS) so I can't get an elearning lesson to send data to the opener page
> that communicates with the learning management system (LMS).
> 
> Given that iOS currently displays all web pages full screen,

It does not.

> My problem now is, how can I reliably tell either if [window.opener] will
> not "work" or if the browser is always full screen?

You cannot.  Especially on mobile devices, you need to abandon the idea that 
windows/frames would be viable/the only ways of the presentation of related 
content in a Web application.

-- 
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]

#25013 — Re: Detect Browser full screen Or window.opener

On 24/06/2014 8:48 PM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> It seems that [window.opener] [yields] undefined (at least with Chrome on
>> iOS) so I can't get an elearning lesson to send data to the opener page
>> that communicates with the learning management system (LMS).
>>
>> Given that iOS currently displays all web pages full screen,
>
> It does not.

Perhaps I should've said the browser app always displays at full screen.

>> My problem now is, how can I reliably tell either if [window.opener] will
>> not "work" or if the browser is always full screen?
>
> You cannot.  Especially on mobile devices, you need to abandon the idea that
> windows/frames would be viable/the only ways of the presentation of related
> content in a Web application.

I cannot install an app on individual devices and the elearning lesson 
will be in the cloud so besides standalone apps, how else could a web 
application be presented on mobile devices if not in a browser?

Andrew Poulos

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

#25015 — Re: Detect Browser full screen Or window.opener

Andrew Poulos wrote:

> On 24/06/2014 8:48 PM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> My problem now is, how can I reliably tell either if [window.opener]
>>> will not "work" or if the browser is always full screen?
>>
>> You cannot.  Especially on mobile devices, you need to abandon the idea
>> that windows/frames would be viable/the only ways of the presentation of
>> related content in a Web application.
> 
> I cannot install an app on individual devices and the elearning lesson
> will be in the cloud so besides standalone apps, how else could a web
> application be presented on mobile devices if not in a browser?

I have not said that you need to abandon the idea of a Web browser.

-- 
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]

#25016 — Re: Detect Browser full screen Or window.opener

On 25/06/2014 7:45 AM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> On 24/06/2014 8:48 PM, Thomas 'PointedEars' Lahn wrote:
>>> Andrew Poulos wrote:
>>>> My problem now is, how can I reliably tell either if [window.opener]
>>>> will not "work" or if the browser is always full screen?
>>>
>>> You cannot.  Especially on mobile devices, you need to abandon the idea
>>> that windows/frames would be viable/the only ways of the presentation of
>>> related content in a Web application.
>>
>> I cannot install an app on individual devices and the elearning lesson
>> will be in the cloud so besides standalone apps, how else could a web
>> application be presented on mobile devices if not in a browser?
>
> I have not said that you need to abandon the idea of a Web browser.

I'm at a loss. How else would you propose that content could be 
presented in a browser without using windows/frames?

Andrew Poulos

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

#25017 — Re: Detect Browser full screen Or window.opener

At Wed, 25 Jun 2014 08:44:54 +1000 Andrew Poulos <ap_prog@hotmail.com> wrote:

> 
> On 25/06/2014 7:45 AM, Thomas 'PointedEars' Lahn wrote:
> > Andrew Poulos wrote:
> >
> >> On 24/06/2014 8:48 PM, Thomas 'PointedEars' Lahn wrote:
> >>> Andrew Poulos wrote:
> >>>> My problem now is, how can I reliably tell either if [window.opener]
> >>>> will not "work" or if the browser is always full screen?
> >>>
> >>> You cannot.  Especially on mobile devices, you need to abandon the idea
> >>> that windows/frames would be viable/the only ways of the presentation of
> >>> related content in a Web application.
> >>
> >> I cannot install an app on individual devices and the elearning lesson
> >> will be in the cloud so besides standalone apps, how else could a web
> >> application be presented on mobile devices if not in a browser?
> >
> > I have not said that you need to abandon the idea of a Web browser.
> 
> I'm at a loss. How else would you propose that content could be 
> presented in a browser without using windows/frames?

I think that what Thomas is suggesting is that using *popups* (eg 
window.open()) might not work well on mobile devices.  Either you need to have 
way too much fun with JavaScript and CSS to 'fake' dialogs or you just have to 
live with the *single* open browser window.

> 
> Andrew Poulos
> 
>                                      

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                         

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

#25018 — Re: Detect Browser full screen Or window.opener

Andrew Poulos wrote:

> On 25/06/2014 7:45 AM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> On 24/06/2014 8:48 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Andrew Poulos wrote:
>>>>> My problem now is, how can I reliably tell either if [window.opener]
>>>>> will not "work" or if the browser is always full screen?
>>>> You cannot.  Especially on mobile devices, you need to abandon the idea
>>>> that windows/frames would be viable/the only ways of the presentation
>>>> of related content in a Web application.
>>> I cannot install an app on individual devices and the elearning lesson
>>> will be in the cloud so besides standalone apps, how else could a web
>>> application be presented on mobile devices if not in a browser?
>> I have not said that you need to abandon the idea of a Web browser.
> 
> I'm at a loss. How else would you propose that content could be
> presented in a browser without using windows/frames?

I do not know the specifics of your application, but in general you can 
display other block-level elements on top of the current document instead.  
Their (related) content can be generated (partially) from the response to an 
HTTP request made with XHR.  Look into DOM2+, HTML5, CSS2+, and REST.

<https://developer.mozilla.org/en-US/docs/>

-- 
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