popup focus() behaviour with moz, firefox, ie

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Alex.Svetos@gmail.com

    popup focus() behaviour with moz, firefox, ie

    Hello,

    I'm trying to get a popup to keep focus when it is re-clicked.
    The script below is supposed to produce this exact behaviour,
    however it doesn't work, at least on firefox 1.0.7 and moz 1.7.12
    (linux kubuntu). It does work with konqueror.
    It seems to work with firefox on windows but not with IE (not completly
    sure though).


    <script type="text/javascript">
    var WindowObjectRef erence = null; // global variable

    function openFFPromotion Popup()
    {
    if(WindowObject Reference == null || WindowObjectRef erence.closed)
    /* if the pointer to the window object in memory does not exist
    or if such pointer exists but the window was closed */

    {
    WindowObjectRef erence =
    window.open("ht tp://www.spreadfiref ox.com/",
    "PromoteFirefox WindowName",
    "resizable=yes, scrollbars=yes, status=yes");
    /* then create it. The new window will be created and
    will be brought on top of any other window. */
    }
    else
    {
    WindowObjectRef erence.focus();
    /* else the window reference must exist and the window
    is not closed; therefore, we can bring it back on top of any
    other
    window with the focus() method. There would be no need to
    re-create
    the window or to reload the referenced resource. */
    };
    }
    </script>

    (...)

    <p><a href="http://www.spreadfiref ox.com/"
    target="Promote FirefoxWindowNa me"
    onclick="openFF PromotionPopup( ); return false;"
    title="This link will create a new window or will re-use
    an already opened one">Promote Firefox adoption</a></p>


    The weird thing is... it is copied from
    http://developer.mozilla.org/en/docs....open#Examples !

    I must mention that i've activated javscript and allowed it to control
    focus with firefox and even disabled bpopup blocking, but it didn't
    helped :(, neither did the many variante i've found on the web or in
    this newsgroup.

    I'm really clueless, but i'm just catching up with javascript so i hope
    i've missed an obvious point.




    So if anyone

  • Thomas 'PointedEars' Lahn

    #2
    Re: popup focus() behaviour with moz, firefox, ie

    Alex.Svetos@gma il.com wrote:
    [color=blue]
    > I'm trying to get a popup to keep focus when it is re-clicked.[/color]

    Don't.


    PointedEars

    Comment

    • Alex.Svetos@gmail.com

      #3
      Re: popup focus() behaviour with moz, firefox, ie

      >Don't.
      thx a lot ah

      Comment

      • Thomas 'PointedEars' Lahn

        #4
        Re: popup focus() behaviour with moz, firefox, ie

        Alex.Svetos@gma il.com wrote:
        [color=blue][color=green]
        >> Don't.[/color]
        > thx a lot ah[/color]

        My first followup probably was not enlightening enough ;-)

        The reason why what you are trying to do is a Bad Thing:

        <URL:http://www.faqs.org/faqs/x-faq/part7/section-42.html>
        (This is about programming for the X Window System, but I'm sure you get the
        idea anyway.)

        Focusing the window most certainly does not work with your Gecko-based
        UAs because there are Preferences with which the user can prevent you
        from "stealing" the focus, that are enabled by default. Too many
        clueless script-kiddies have attempted this in the past.

        Please provide attribution of quoted material next time:

        <URL:http://jibbering.com/faq/faq_notes/pots1.html>
        <URL:http://www.safalra.com/special/googlegroupsrep ly/>


        PointedEars

        Comment

        • Alex.Svetos@gmail.com

          #5
          Re: popup focus() behaviour with moz, firefox, ie

          Thomas 'PointedEars' Lahn a écrit :
          [color=blue]
          > Alex.Svetos@gma il.com wrote:
          >[color=green][color=darkred]
          > >> Don't.[/color]
          > > thx a lot ah[/color]
          >
          > My first followup probably was not enlightening enough ;-)
          >
          > The reason why what you are trying to do is a Bad Thing:
          >
          > <URL:http://www.faqs.org/faqs/x-faq/part7/section-42.html>
          > (This is about programming for the X Window System, but I'm sure you get the
          > idea anyway.)
          >
          > Focusing the window most certainly does not work with your Gecko-based
          > UAs because there are Preferences with which the user can prevent you
          > from "stealing" the focus, that are enabled by default. Too many
          > clueless script-kiddies have attempted this in the past.[/color]

          You certainly didn't read my post, i'm not trying to get a popup
          constantly on top as you say, but simply to get it on top again when
          you click on the main page link.
          Once again the preferences to allow it are set in firefox.

          Both of your replies are disrespectfull.

          Comment

          • ASM

            #6
            Re: popup focus() behaviour with moz, firefox, ie

            Alex.Svetos@gma il.com a écrit :[color=blue]
            >
            > You certainly didn't read my post, i'm not trying to get a popup
            > constantly on top as you say, but simply to get it on top again when
            > you click on the main page link.[/color]

            Was your post very understanding ?
            "I'm trying to get a popup to keep focus when it is re-clicked."
            which is a non sens : if popup is clicked it has/get focus

            So what we'll remember except 'keep focus' ?
            (bad thing to do)

            The script you've given is (allmost) correct and have to run as is
            - a new popup on 1st call
            - same popup comming to front with next calls
            [color=blue]
            > Once again the preferences to allow it are set in firefox.[/color]

            I never fix preferences to stop all popups, only those comming automaticaly.
            How to imagine you did stop all popups.
            [color=blue]
            > Both of your replies are disrespectfull.[/color]

            Not first one
            Please try to re-read yourself.



            --
            Stephane Moriaux et son [moins] vieux Mac

            Comment

            • Thomas 'PointedEars' Lahn

              #7
              Re: popup focus() behaviour with moz, firefox, ie

              Alex.Svetos@gma il.com wrote:
              [color=blue]
              > Thomas 'PointedEars' Lahn a écrit :[color=green]
              >> Alex.Svetos@gma il.com wrote:[color=darkred]
              >> >> Don't.
              >> > thx a lot ah[/color]
              >>
              >> My first followup probably was not enlightening enough ;-)
              >>
              >> The reason why what you are trying to do is a Bad Thing:
              >>
              >> <URL:http://www.faqs.org/faqs/x-faq/part7/section-42.html>
              >> (This is about programming for the X Window System, but I'm sure you get
              >> the idea anyway.)
              >>
              >> Focusing the window most certainly does not work with your Gecko-based
              >> UAs because there are Preferences with which the user can prevent you
              >> from "stealing" the focus, that are enabled by default. Too many
              >> clueless script-kiddies have attempted this in the past.[/color]
              >
              > You certainly didn't read my post,[/color]

              Certainly I could not read your thoughts.
              [color=blue]
              > i'm not trying to get a popup constantly on top as you say,[/color]

              | I'm trying to get a popup to keep focus when it is re-clicked.

              You will excuse me if "keep" reads as "constantly " to me.
              [color=blue]
              > but simply to get it on top again when you click on the main page link.[/color]

              OK.
              [color=blue]
              > Once again the preferences to allow it are set in firefox.[/color]

              Sorry, I missed that.
              [color=blue]
              > Both of your replies are disrespectfull.[/color]

              No, it was not. Besides, respect has to be earned, and you got what you
              paid for.

              Besides:

              | The weird thing is... it is copied from
              | http://developer.mozilla.org/en/docs....open#Examples

              MDC is a Wiki, so anybody can post nonsense there (and partially did in this
              case). However, the code you have posted (which is not necessarily the
              code you are using) works here (provided _all_ prefs are set accordingly).

              There can be several reasons why it would not work with you. Try
              to find them out by debugging the code. See also the lower part of
              news:1557154.op sxikCCRk@Pointe dEars.de


              Score adjusted

              PointedEars

              Comment

              • Csaba Gabor

                #8
                Re: popup focus() behaviour with moz, firefox, ie

                Alex.Svetos@gma il.com wrote:[color=blue]
                > I'm trying to get a popup to keep focus when it is re-clicked.[/color]

                As you understand by now, this statement of the problem is
                incorrect. Rather, you are trying to have a previously created
                popup regain focus when a link or button activating it is
                clicked.
                [color=blue]
                > The script below is supposed to produce this exact behaviour,
                > however it doesn't work, at least on firefox 1.0.7 and moz 1.7.12
                > (linux kubuntu). It does work with konqueror.
                > It seems to work with firefox on windows but not with IE (not completly
                > sure though).[/color]

                Indeed, this is a classic case of protectionism run amok.
                IE and FF both let you create a named window which they will bring to
                the top, especially provided that it was some user instigated
                through some user initiated action, such as clicking.

                To be clear, this is not a case of a window/app trying to
                raise itself to the top. The main window is already at the top,
                so if it wants to have a child window come to the top (which may
                be viewed as part of the same (already in focus) application),
                which it could do anyway with window.open, what is the problem
                in allowing window.focus()?

                That is to say, it makes eminent sense that if a window, B,
                which was created by window A, comes to the top upon creation,
                that the same window B should come to the top upon a user
                initiated action leading to windowB.focus() The really silly
                way around this is to close windowB and then recreate it, which
                only serves to drive up internet traffic.

                This problem and two ways of dealing with it on FF are described at

                If you agree with the assessment, I suggest voting for the bug
                to give it more visibility.

                Unfortunately, I don't know of a nice workaround (other than the
                brute force method in the bug report) for my IE 6 on Win XP Pro.
                IE will flash the tab at the bottom of my window, but that's a
                poor substitute for bringing it to the top.

                Csaba Gabor from Vienna

                Comment

                • Gérard Talbot

                  #9
                  Re: popup focus() behaviour with moz, firefox, ie

                  Alex.Svetos@gma il.com wrote :[color=blue]
                  > Thomas 'PointedEars' Lahn a écrit :
                  >[color=green]
                  >> Alex.Svetos@gma il.com wrote:
                  >>[color=darkred]
                  >>>> Don't.
                  >>> thx a lot ah[/color]
                  >> My first followup probably was not enlightening enough ;-)
                  >>
                  >> The reason why what you are trying to do is a Bad Thing:
                  >>
                  >> <URL:http://www.faqs.org/faqs/x-faq/part7/section-42.html>
                  >> (This is about programming for the X Window System, but I'm sure you get the
                  >> idea anyway.)
                  >>
                  >> Focusing the window most certainly does not work with your Gecko-based
                  >> UAs because there are Preferences with which the user can prevent you
                  >> from "stealing" the focus, that are enabled by default. Too many
                  >> clueless script-kiddies have attempted this in the past.[/color]
                  >
                  > You certainly didn't read my post, i'm not trying to get a popup
                  > constantly on top as you say, but simply to get it on top again when
                  > you click on the main page link.
                  > Once again the preferences to allow it are set in firefox.[/color]

                  Such preference and control is entirely up to the user if he finds the
                  setting and understand how good or bad the setting can be for his web
                  experience. Chances are that a very wide majority of users won't know
                  what "Raise or lower windows" implies and means, so they will trust the
                  default Firefox setting and will not allow your script to bring back the
                  secondary window when clicking the link again.

                  I am personally against the current default value. I tried to educate
                  the people on what that setting means.
                  See

                  But then again, if the content is important to be read, seen, then I do
                  not recommend that you use a secondary window.

                  Thomas 'PointedEars' Lahn is abrasive, arrogant, even hostile at times
                  but he's right about not relying, not hoping too much on a focus() call
                  to work, at least, all the times. It's all up to the user in the final
                  instance. And, if your webpage design is sound, accessibility-oriented,
                  then even users with "Raise or lower windows" unchecked should be able
                  to access your content without a problem. Chances are that if you follow
                  the usability guidelines and recommendations given at
                  The open() method of the Window interface loads a specified resource into a new or existing browsing context (that is, a tab, a window, or an iframe) under a specified name.

                  then the user will know there is another secondary window and
                  tab-capable browser users will not open your document in a secondary
                  window but most likely into a tab.

                  Gérard
                  --
                  remove blah to email me

                  Comment

                  • Gérard Talbot

                    #10
                    Re: popup focus() behaviour with moz, firefox, ie

                    Csaba Gabor wrote :[color=blue]
                    > Alex.Svetos@gma il.com wrote:[color=green]
                    >> I'm trying to get a popup to keep focus when it is re-clicked.[/color]
                    >
                    > As you understand by now, this statement of the problem is
                    > incorrect. Rather, you are trying to have a previously created
                    > popup regain focus when a link or button activating it is
                    > clicked.
                    >[color=green]
                    >> The script below is supposed to produce this exact behaviour,
                    >> however it doesn't work, at least on firefox 1.0.7 and moz 1.7.12
                    >> (linux kubuntu). It does work with konqueror.
                    >> It seems to work with firefox on windows but not with IE (not completly
                    >> sure though).[/color]
                    >
                    > Indeed, this is a classic case of protectionism run amok.
                    > IE and FF both let you create a named window which they will bring to
                    > the top, especially provided that it was some user instigated
                    > through some user initiated action, such as clicking.
                    >[/color]

                    It's not that simple. A secondary window could have been brought up
                    legitimately; after some time, it could be reloaded with advertisement
                    content. Or who knows; a second click on a link could load a different
                    document. There are lots of possibilities, variations which a persistent
                    scripter could take advantage of.
                    [color=blue]
                    > To be clear, this is not a case of a window/app trying to
                    > raise itself to the top.[/color]

                    A setTimeout can do that though.
                    Some people create a modal window with
                    <body onblur="self.fo cus();">
                    you see.

                    The main window is already at the top,[color=blue]
                    > so if it wants to have a child window come to the top (which may
                    > be viewed as part of the same (already in focus) application),
                    > which it could do anyway with window.open, what is the problem
                    > in allowing window.focus()?
                    >[/color]

                    The window is not per se the problem: its content (actual, future,
                    potential) is. When a browser prevents an unrequested popup, it's not so
                    much the window that is the problem as it is its content (advertisement,
                    spamming content, annoyance of being served scam ads or anything which
                    is not related to the reasons to visit a site in the first place).

                    If you visit some sites like netscape.com and yahoo.com, they are now
                    using DHTML layers to convey advertisement. No secondary windows
                    involved. But the same boring, annoying advertisement pollution.
                    [color=blue]
                    > That is to say, it makes eminent sense that if a window, B,
                    > which was created by window A, comes to the top upon creation,
                    > that the same window B should come to the top upon a user
                    > initiated action leading to windowB.focus() The really silly
                    > way around this is to close windowB and then recreate it,[/color]

                    There are scripts available on the web that do exactly that: as the user
                    reclicks the link, the script closes windowB and then recreate it entirely.

                    See the 9th link at


                    which[color=blue]
                    > only serves to drive up internet traffic.
                    >
                    > This problem and two ways of dealing with it on FF are described at
                    > https://bugzilla.mozilla.org/show_bug.cgi?id=318535
                    > If you agree with the assessment, I suggest voting for the bug
                    > to give it more visibility.
                    >[/color]

                    The bug hasn't even been confirmed yet!
                    And the bug is about respecting and maintaining user settings when
                    upgrading Fx.
                    [color=blue]
                    > Unfortunately, I don't know of a nice workaround (other than the
                    > brute force method in the bug report) for my IE 6 on Win XP Pro.[/color]

                    How about simply not using window.open() if your content is important
                    for the users to read, otherwise warn accordingly users about a
                    secondary window and do not rely too much on such window.open() +
                    window.focus() call.

                    Gérard
                    --
                    remove blah to email me

                    Comment

                    • Csaba  Gabor

                      #11
                      Re: popup focus() behaviour with moz, firefox, ie

                      Gérard Talbot wrote:[color=blue]
                      > Csaba Gabor wrote :[color=green]
                      > > Alex.Svetos@gma il.com wrote:[color=darkred]
                      > >> I'm trying to get a popup to keep focus when it is re-clicked.[/color]
                      > >
                      > > As you understand by now, this statement of the problem is
                      > > incorrect. Rather, you are trying to have a previously created
                      > > popup regain focus when a link or button activating it is
                      > > clicked.
                      > > ...
                      > > Indeed, this is a classic case of protectionism run amok.
                      > > IE and FF both let you create a named window which they will bring to
                      > > the top, especially provided that it was some user instigated
                      > > through some user initiated action, such as clicking.[/color]
                      >
                      > It's not that simple. A secondary window could have been brought up
                      > legitimately; after some time, it could be reloaded with advertisement
                      > content. Or who knows; a second click on a link could load a different
                      > document. There are lots of possibilities, variations which a persistent
                      > scripter could take advantage of.[/color]

                      I'm not quite following your scenario and objection (advantage taking
                      mechanism). Are you referring to:
                      1) Window A brings up named window B, and then A or B later reload B
                      (which they are entitled to do)
                      2) Window A brings up named window B, and then a different window C in
                      the same domain loads up B with new content. So at this point, is
                      either A, B, or C allowed to (or ought to be allowed to) do a .focus()?
                      3) Window A brings up named window B, and then a different window C in
                      a different domain loads up B with new content.
                      4) Something else.

                      It would be nice if you would clarify specific scenario(s) that you
                      have an issue with that the popup blocker does not protect against (ie.
                      how could a persistent scripter take advantage?).
                      [color=blue][color=green]
                      > > To be clear, this is not a case of a window/app trying to
                      > > raise itself to the top.[/color]
                      >
                      > A setTimeout can do that though.
                      > Some people create a modal window with
                      > <body onblur="self.fo cus();">
                      > you see.[/color]

                      I like this because it's a specific instance that we can discuss.
                      Woudn't it make sense to have window/self.focus() labor under the same
                      restrictions as window.open? In other words, it has to be initiated by
                      a physical user event within a certain time limit to have any effect.

                      To go on a bit of a digression, the kind of behaviour you have
                      mentioned can be achieved by an infinite loop of alerts. A solution to
                      this would be to have FF always allow the underlying window to be
                      closed (by, for example, clicking on its X button in the upper right
                      corner or by having a context menu for close on the right click if the
                      X is not visible).
                      [color=blue]
                      > The main window is already at the top,[color=green]
                      > > so if it wants to have a child window come to the top (which may
                      > > be viewed as part of the same (already in focus) application),
                      > > which it could do anyway with window.open, what is the problem
                      > > in allowing window.focus()?
                      > >[/color]
                      > The window is not per se the problem: its content (actual, future,
                      > potential) is. When a browser prevents an unrequested popup, it's not so
                      > much the window that is the problem as it is its content (advertisement,
                      > spamming content, annoyance of being served scam ads or anything which
                      > is not related to the reasons to visit a site in the first place).
                      >
                      > If you visit some sites like netscape.com and yahoo.com, they are now
                      > using DHTML layers to convey advertisement. No secondary windows
                      > involved. But the same boring, annoying advertisement pollution.[/color]

                      This is off topic for this thread. I hate those kinds of ads, too.
                      However, opposition to popups has its basis in the fact that the user
                      chose to look at a website in a given window, and that window is all
                      the website is entitled to, except under limited circumstances (user
                      initiated actions). However, this argument does not apply to the
                      content of the web page itself. That browser window is the website's
                      playground and if they want to annoy users by placing ads, that's their
                      prerogative. That's what GreaseMonkey helps with.
                      [color=blue][color=green]
                      > > That is to say, it makes eminent sense that if a window, B,
                      > > which was created by window A, comes to the top upon creation,
                      > > that the same window B should come to the top upon a user
                      > > initiated action leading to windowB.focus() The really silly
                      > > way around this is to close windowB and then recreate it,[/color]
                      >
                      > There are scripts available on the web that do exactly that: as the user
                      > reclicks the link, the script closes windowB and then recreate it entirely.
                      >
                      > See the 9th link at
                      > https://bugzilla.mozilla.org/attachm...49&action=view[/color]

                      What is the id of the associated bug ... How do I use the search page
                      at
                      https://bugzilla.mozilla.org/query.cgi to figure out the bug associated
                      with a given attachment number?
                      And by the way, what is the bug that you are referring to in your last
                      post in

                      The link is broken.

                      Anyway, I am not fond of this idea of killing windows one is going to
                      reuse just to get them to the top.
                      [color=blue]
                      > which[color=green]
                      > > only serves to drive up internet traffic.
                      > >
                      > > This problem and two ways of dealing with it on FF are described at
                      > > https://bugzilla.mozilla.org/show_bug.cgi?id=318535
                      > > If you agree with the assessment, I suggest voting for the bug
                      > > to give it more visibility.
                      > >[/color]
                      >
                      > The bug hasn't even been confirmed yet![/color]

                      What is your point?
                      [color=blue]
                      > And the bug is about respecting and maintaining user settings when
                      > upgrading Fx.[/color]

                      That is half the bug. But it is also about allowing window.focus() to
                      focus a window that the caller has rights to.
                      [color=blue][color=green]
                      > > Unfortunately, I don't know of a nice workaround (other than the
                      > > brute force method in the bug report) for my IE 6 on Win XP Pro.[/color]
                      >
                      > How about simply not using window.open() if your content is important
                      > for the users to read, otherwise warn accordingly users about a
                      > secondary window and do not rely too much on such window.open() +
                      > window.focus() call.[/color]

                      I have a web app for rapid development/prototyping. You put the input
                      source material into a textbox in one window, press alt+s and up pops
                      the result in the second window. For this type of scenario it makes
                      sense for the content to be delivered to a second window and for the
                      second window to remain where it is and for the second window to rise
                      to the top. Any kind of per instance warning is not a solution.

                      The user could always allow scripts to raise or lower windows (by the
                      way, would you happen to know the corresponding pref.js setting?), but
                      that allows access for any script. I am only suggesting that in
                      situations where window.open would raise a new window to the top, there
                      is nothing that is lost by allowing window.focus() to do the same.

                      Comment

                      • Gérard Talbot

                        #12
                        Re: popup focus() behaviour with moz, firefox, ie

                        Csaba Gabor wrote :[color=blue]
                        > Gérard Talbot wrote:[color=green]
                        >> Csaba Gabor wrote :[color=darkred]
                        >>> Alex.Svetos@gma il.com wrote:
                        >>>> I'm trying to get a popup to keep focus when it is re-clicked.
                        >>> As you understand by now, this statement of the problem is
                        >>> incorrect. Rather, you are trying to have a previously created
                        >>> popup regain focus when a link or button activating it is
                        >>> clicked.
                        >>> ...
                        >>> Indeed, this is a classic case of protectionism run amok.
                        >>> IE and FF both let you create a named window which they will bring to
                        >>> the top, especially provided that it was some user instigated
                        >>> through some user initiated action, such as clicking.[/color]
                        >> It's not that simple. A secondary window could have been brought up
                        >> legitimately; after some time, it could be reloaded with advertisement
                        >> content. Or who knows; a second click on a link could load a different
                        >> document. There are lots of possibilities, variations which a persistent
                        >> scripter could take advantage of.[/color]
                        >
                        > I'm not quite following your scenario and objection (advantage taking
                        > mechanism). Are you referring to:
                        > 1) Window A brings up named window B, and then A or B later reload B
                        > (which they are entitled to do)
                        > 2) Window A brings up named window B, and then a different window C in
                        > the same domain loads up B with new content. So at this point, is
                        > either A, B, or C allowed to (or ought to be allowed to) do a .focus()?
                        > 3) Window A brings up named window B, and then a different window C in
                        > a different domain loads up B with new content.
                        > 4) Something else.
                        >
                        > It would be nice if you would clarify specific scenario(s) that you
                        > have an issue with that the popup blocker does not protect against (ie.
                        > how could a persistent scripter take advantage?).
                        >[/color]

                        I was thinking of scenario 2 where document loaded in window A can
                        focus() document #3 in window B after being loaded.
                        [color=blue][color=green][color=darkred]
                        >>> To be clear, this is not a case of a window/app trying to
                        >>> raise itself to the top.[/color]
                        >> A setTimeout can do that though.
                        >> Some people create a modal window with
                        >> <body onblur="self.fo cus();">
                        >> you see.[/color]
                        >
                        > I like this because it's a specific instance that we can discuss.
                        > Woudn't it make sense to have window/self.focus() labor under the same
                        > restrictions as window.open? In other words, it has to be initiated by
                        > a physical user event within a certain time limit to have any effect.[/color]


                        Yes, it would make sense to have focus() work under the same
                        restrictions as window.open().

                        [color=blue]
                        > To go on a bit of a digression, the kind of behaviour you have
                        > mentioned can be achieved by an infinite loop of alerts.[/color]

                        Exactly. I happened to have demonstrated this in 2002 in a netscape7
                        newsgroup.

                        A solution to[color=blue]
                        > this would be to have FF always allow the underlying window to be
                        > closed (by, for example, clicking on its X button in the upper right
                        > corner or by having a context menu for close on the right click if the
                        > X is not visible).
                        >[/color]

                        An alert is a modal window; not any kind of normal secondary window. You
                        can not reach the parent-opener without first closing the modal window.
                        The modal window's opener can not be focused without first closing the
                        modal window.
                        [color=blue][color=green]
                        >> The main window is already at the top,[color=darkred]
                        >>> so if it wants to have a child window come to the top (which may
                        >>> be viewed as part of the same (already in focus) application),
                        >>> which it could do anyway with window.open, what is the problem
                        >>> in allowing window.focus()?
                        >>>[/color]
                        >> The window is not per se the problem: its content (actual, future,
                        >> potential) is. When a browser prevents an unrequested popup, it's not so
                        >> much the window that is the problem as it is its content (advertisement,
                        >> spamming content, annoyance of being served scam ads or anything which
                        >> is not related to the reasons to visit a site in the first place).
                        >>
                        >> If you visit some sites like netscape.com and yahoo.com, they are now
                        >> using DHTML layers to convey advertisement. No secondary windows
                        >> involved. But the same boring, annoying advertisement pollution.[/color]
                        >
                        > This is off topic for this thread. I hate those kinds of ads, too.
                        > However, opposition to popups has its basis in the fact that the user
                        > chose to look at a website in a given window, and that window is all
                        > the website is entitled to, except under limited circumstances (user
                        > initiated actions). However, this argument does not apply to the
                        > content of the web page itself. That browser window is the website's
                        > playground and if they want to annoy users by placing ads, that's their
                        > prerogative. That's what GreaseMonkey helps with.
                        >[/color]

                        It may not be that off topic. I was merely pointing out that it is
                        unwanted polluting content that annoy us. Put it into a DHTML layer or
                        in a window: in both cases, the users' system resources are used and
                        abused to annoy the users.
                        [color=blue][color=green][color=darkred]
                        >>> That is to say, it makes eminent sense that if a window, B,
                        >>> which was created by window A, comes to the top upon creation,
                        >>> that the same window B should come to the top upon a user
                        >>> initiated action leading to windowB.focus() The really silly
                        >>> way around this is to close windowB and then recreate it,[/color]
                        >> There are scripts available on the web that do exactly that: as the user
                        >> reclicks the link, the script closes windowB and then recreate it entirely.
                        >>
                        >> See the 9th link at
                        >> https://bugzilla.mozilla.org/attachm...49&action=view[/color]
                        >
                        > What is the id of the associated bug ... How do I use the search page
                        > at
                        > https://bugzilla.mozilla.org/query.cgi to figure out the bug associated
                        > with a given attachment number?[/color]

                        Titlebar or source code were indicating
                        <title>Testca se for bug 151142 and other related bugs</title>
                        [color=blue]
                        > And by the way, what is the bug that you are referring to in your last
                        > post in
                        > http://groups.google.com/group/comp....d28fdaac54b3c/
                        > The link is broken.
                        >[/color]

                        I restructured my website recently. I will eventually remove all
                        references to NS 7.

                        What does the "Raise or lower windows" setting do exactly?


                        [color=blue]
                        > Anyway, I am not fond of this idea of killing windows one is going to
                        > reuse just to get them to the top.
                        >[/color]

                        I certainly do not either: it's really a bad idea, abusing the users'
                        system resources.

                        [color=blue][color=green]
                        >> which[color=darkred]
                        >>> only serves to drive up internet traffic.
                        >>>
                        >>> This problem and two ways of dealing with it on FF are described at
                        >>> https://bugzilla.mozilla.org/show_bug.cgi?id=318535
                        >>> If you agree with the assessment, I suggest voting for the bug
                        >>> to give it more visibility.
                        >>>[/color]
                        >> The bug hasn't even been confirmed yet![/color]
                        >
                        > What is your point?
                        >[/color]

                        My first point is that this bugreport is not well done and second point
                        it's not the correct bugreport to vote for if you want "Raise or lower
                        windows" to default to true, to have the default to allow scripts to
                        Raise or lower windows.
                        [color=blue][color=green]
                        >> And the bug is about respecting and maintaining user settings when
                        >> upgrading Fx.[/color]
                        >
                        > That is half the bug. But it is also about allowing window.focus() to
                        > focus a window that the caller has rights to.[/color]

                        A bugreport should always about 1 single issue per bug. And it should be
                        terse, clear and as clean as possible. In other words, no rant, no long
                        lecture. Bugzilla is not a newsgroup discussion forum, a place for
                        advocacy or debates, actually. It's only a place to report, investigate,
                        then confirm, test patches, fix bugs.
                        [color=blue]
                        >[color=green][color=darkred]
                        >>> Unfortunately, I don't know of a nice workaround (other than the
                        >>> brute force method in the bug report) for my IE 6 on Win XP Pro.[/color]
                        >> How about simply not using window.open() if your content is important
                        >> for the users to read, otherwise warn accordingly users about a
                        >> secondary window and do not rely too much on such window.open() +
                        >> window.focus() call.[/color]
                        >
                        > I have a web app for rapid development/prototyping. You put the input
                        > source material into a textbox in one window, press alt+s and up pops
                        > the result in the second window. For this type of scenario it makes
                        > sense for the content to be delivered to a second window and for the
                        > second window to remain where it is and for the second window to rise
                        > to the top. Any kind of per instance warning is not a solution.
                        >
                        > The user could always allow scripts to raise or lower windows (by the
                        > way, would you happen to know the corresponding pref.js setting?),[/color]


                        dom.disable_win dow_flip


                        but[color=blue]
                        > that allows access for any script. I am only suggesting that in
                        > situations where window.open would raise a new window to the top, there
                        > is nothing that is lost by allowing window.focus() to do the same.
                        >[/color]


                        Gérard
                        --
                        remove blah to email me

                        Comment

                        Working...