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

Groups > linux.debian.user > #275417 > unrolled thread

Firefox and XFCE

Back to article view | Back to linux.debian.user

Contents

  Firefox and XFCE keller.steve@gmx.de - 2024-12-09 12:40 +0100
    Re: Firefox and XFCE Mike Castle <dalgoda+debian@gmail.com> - 2024-12-10 20:00 +0100
      Re: Firefox and XFCE keller.steve@gmx.de - 2024-12-17 13:20 +0100
        Re: Firefox and XFCE Mike Castle <dalgoda+debian@gmail.com> - 2024-12-17 17:50 +0100
        Re: Firefox and XFCE Max Nikulin <manikulin@gmail.com> - 2024-12-18 14:10 +0100
          Re: Firefox and XFCE keller.steve@gmx.de - 2024-12-25 08:30 +0100
            Re: Firefox and XFCE Greg Wooledge <greg@wooledge.org> - 2024-12-25 15:10 +0100
            Re: Firefox and XFCE Max Nikulin <manikulin@gmail.com> - 2024-12-26 04:20 +0100
              Re: Firefox and XFCE Greg Wooledge <greg@wooledge.org> - 2024-12-26 04:20 +0100
                Re: Firefox and XFCE <tomas@tuxteam.de> - 2024-12-26 08:00 +0100
                  Re: Firefox and XFCE Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-26 17:20 +0100
                    Who's the window manager's boss? [was: Firefox and XFCE] <tomas@tuxteam.de> - 2024-12-27 00:10 +0100
                      Re: Who's the window manager's boss? [was: Firefox and XFCE] Andy Smith <andy@strugglers.net> - 2024-12-27 13:40 +0100
                        Re: Who's the window manager's boss? [was: Firefox and XFCE] Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-27 17:20 +0100
                          Re: Who's the window manager's boss? [was: Firefox and XFCE] Andy Smith <andy@strugglers.net> - 2024-12-27 19:10 +0100
                            Re: Who's the window manager's boss? [was: Firefox and XFCE] Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-27 19:40 +0100
              Re: Firefox and XFCE Eike Lantzsch ZP5CGE / KY4PZ <zp6cge@gmx.net> - 2024-12-26 10:50 +0100
                Re: Firefox and XFCE Max Nikulin <manikulin@gmail.com> - 2024-12-27 03:40 +0100

#275417 — Firefox and XFCE

I have Debian 12 with XFCE and firefox on my Laptop.  The XFCE window
manager is configured such that a window is not raised when I click or
double click (select) inside it.  This works for all X11 windows
except for firefox, which is raised when I click inside.

Why is firefox's behavior so different and how can I change it?

Steve

[toc] | [next] | [standalone]

#275465

Out of curiosity, how do you raise windows?

Anyway, I was unable to reproduce this with FF 1.333.0 and Debian 12.
However, I normally do not run with these settings, so perhaps I do
not have them set up correctly.

Perhaps some screen shots of your settings might be in order to verify
I tried correctly.

Similarly, a copy of your FF prefs.js (sanitized, of course).  This
file would be in your profile directory and contains only values that
are different from built in defaults.

I also presume that this just recently started happening, and you have
tried restarting both FF and logging out/in just in case anything
wonky happened during some upgrade.

mrc

On Mon, Dec 9, 2024 at 3:33 AM <keller.steve@gmx.de> wrote:
>
> I have Debian 12 with XFCE and firefox on my Laptop.  The XFCE window
> manager is configured such that a window is not raised when I click or
> double click (select) inside it.  This works for all X11 windows
> except for firefox, which is raised when I click inside.
>
> Why is firefox's behavior so different and how can I change it?
>
> Steve
>

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

#275818

> Mike Castle <dalgoda+debian@gmail.com> writes:
>
> Out of curiosity, how do you raise windows?

I can raise windows by clicking into the title bar or by clicking the
window while holding the left mouse button.

> Similarly, a copy of your FF prefs.js (sanitized, of course).  This
> file would be in your profile directory and contains only values that
> are different from built in defaults.

I have grepped through prefs.js and haven't found anything that sounds
related, i.e. I have searched for "click", "focus", "rais",
"foreground", etc.

> I also presume that this just recently started happening, and you have
> tried restarting both FF and logging out/in just in case anything
> wonky happened during some upgrade.

No, this has been from the installation of Debian 12 to this Laptop.
Before that, I had Xubuntu 20.04 (Ubuntu with XFCE) on another Laptop
that has crashed (broken mainboard).  I also run Xubuntu 18.04 in a
VirtualBox on a Windows host.  Both also configured to not raise on
click and focus follows mouse, and both behave as I want, i.e. firefox
also obeys these settings, like all other X11 programs.

Steve

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

#275834

On Tue, Dec 17, 2024 at 4:12 AM <keller.steve@gmx.de> wrote:
> No, this has been from the installation of Debian 12 to this Laptop.
> Before that, I had Xubuntu 20.04 (Ubuntu with XFCE) on another Laptop
> that has crashed (broken mainboard).  I also run Xubuntu 18.04 in a
> VirtualBox on a Windows host.  Both also configured to not raise on
> click and focus follows mouse, and both behave as I want, i.e. firefox
> also obeys these settings, like all other X11 programs.

Darn.

Without seeing your settings, and being unfamiliar with this kind of
set up, I can't verify why it works for me, but not you.

Since you are comfortable using VMs, maybe try a new set up in a VM
with minimal tweaks and see if you can reproduce there?  No profile
syncing with FF, no copying over of XFCE config files (at least at
first).

Maybe it will help point out some esoteric setting we've overlooked?

mrc

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

#275873

On 17/12/2024 18:55, keller.steve@gmx.de wrote:
> I have grepped through prefs.js and haven't found anything that sounds
> related,

A shot in the dark: does switching between regular window title and 
client-side decorations changes anything? (right click menu for toolbar, 
"customize toolbar")

I believed, it is up to window manager whether to raise application 
window on its request or to just highlight it as requiring attention in 
the taskbar.

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

#276005

Max Nikulin <manikulin@gmail.com> writes:

> On 17/12/2024 18:55, keller.steve@gmx.de wrote:
> > I have grepped through prefs.js and haven't found anything that sounds
> > related,
>
> A shot in the dark: does switching between regular window title and
> client-side decorations changes anything? (right click menu for
> toolbar, "customize toolbar")

What an amazing good shot.  That was exactly it.  It fixed the
unwanted raising of firefox's windows and also stops firefox from
doing its own title bars with different buttons (e.g. no "Roll Up").
I disliked this second behavior also but could live with it.  Now,
both are working fine.  So, thanks a lot.

And I didn't even know about that setting.  So I'm surprised that
Debian sets it as default, as I am sure I haven't changed it.

> I believed, it is up to window manager whether to raise application
> window on its request or to just highlight it as requiring attention
> in the taskbar.

That is my understanding, too.

Steve

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

#276006

On Wed, Dec 25, 2024 at 07:11:11 +0000, keller.steve@gmx.de wrote:
> Max Nikulin <manikulin@gmail.com> writes:
> > A shot in the dark: does switching between regular window title and
> > client-side decorations changes anything? (right click menu for
> > toolbar, "customize toolbar")
> 
> And I didn't even know about that setting.  So I'm surprised that
> Debian sets it as default, as I am sure I haven't changed it.

It's Firefox (upstream) that does it by default.

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

#276009

On 25/12/2024 14:11, keller.steve@gmx.de wrote:
> Max Nikulin writes:
>>
>> does switching between regular window title and
>> client-side decorations changes anything? (right click menu for
>> toolbar, "customize toolbar")
> 
> That was exactly it.  It fixed the
> unwanted raising of firefox's windows and also stops firefox from
> doing its own title bars with different buttons (e.g. no "Roll Up").

You may try to search for mozilla, window manager (fvwm?), gtk bugs or 
discussions related to client-side decoration and rising on click. Are 
there other applications that use CSD and behave in a similar way?

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

#276010

On Thu, Dec 26, 2024 at 10:10:47 +0700, Max Nikulin wrote:
> On 25/12/2024 14:11, keller.steve@gmx.de wrote:
> > Max Nikulin writes:
> > > 
> > > does switching between regular window title and
> > > client-side decorations changes anything? (right click menu for
> > > toolbar, "customize toolbar")
> > 
> > That was exactly it.  It fixed the
> > unwanted raising of firefox's windows and also stops firefox from
> > doing its own title bars with different buttons (e.g. no "Roll Up").
> 
> You may try to search for mozilla, window manager (fvwm?), gtk bugs or
> discussions related to client-side decoration and rising on click. Are there
> other applications that use CSD and behave in a similar way?

Google Chrome also did this thing, I believe, until I configured it.
But it was so long ago that I don't remember what I changed, exactly.

Another program that exhibits this behavior right now is Steam.
When I launch Steam, it sometimes tries to pop up a window showing
current sales promotions or whatever.  However, it's impossible to
raise the sales promotion window to the top so that I can actually
see all of its contents.  It's permanently stuck beneath the main
game window, until I just close it.  I can slide it around the screen
and see part of the content, but that's it.

The idea that your application should do its own window management
because the user's chosen WM may differ from what you, the developer,
wanted is utter hubris.  Especially when you can't even get it to
work the way you thought it should.

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

#276014

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 25, 2024 at 10:17:02PM -0500, Greg Wooledge wrote:

[...]

> The idea that your application should do its own window management
> because the user's chosen WM may differ from what you, the developer,
> wanted is utter hubris.  Especially when you can't even get it to
> work the way you thought it should.

It's not hubris. It's the idea that public space, your computer, your
eyeballs, your brain (in roughly that order) belong to surveillance
capitalism (a malign mutation of the already malign ad industry).

It's the "new frontier" [1] of capitalist accumulation. Robbery, as
it has always been.

Merry XMas.

[1] https://www.schneier.com/blog/archives/2024/02/how-the-frontier-became-the-slogan-of-uncontrolled-ai.html
-- 
t

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

#276023

On 2024-12-26, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
> On Wed, Dec 25, 2024 at 10:17:02PM -0500, Greg Wooledge wrote:
>
> [...]
>
>> The idea that your application should do its own window management
>> because the user's chosen WM may differ from what you, the developer,
>> wanted is utter hubris.  Especially when you can't even get it to
>> work the way you thought it should.
>
> It's not hubris. It's the idea that public space, your computer, your
> eyeballs, your brain (in roughly that order) belong to surveillance
> capitalism (a malign mutation of the already malign ad industry).
>
> It's the "new frontier" [1] of capitalist accumulation. Robbery, as
> it has always been.
>
> Merry XMas.

The tension between application-driven window management and user-driven window
management is a microcosm of broader debates about control, autonomy, and the
influence of external forces in our digital lives.

>From a User Perspective:

The computer and its interface are personal tools, tailored to the individual's
preferences and workflows. Imposing application-specific behavior can feel like
an intrusion, particularly when it disrupts or overrides those workflows.  The
analogy to public and personal spaces is apt: just as urban planning influences
how people navigate physical spaces, the design of software and its interaction
with operating systems dictates how users navigate digital spaces.  From a
Developer Perspective:

The developer's intent often stems from wanting to deliver a cohesive
experience. They might envision their application functioning in a particular
way that requires control over window placement, size, or other behaviors.
However, this desire can veer into hubris if it disregards the diversity of
user environments and expectations.  The Broader Context: Surveillance
capitalism, as mentioned, amplifies these tensions. If applications are
designed not primarily for the user's benefit but for extracting data,
controlling the interface becomes a means to that end. This can manifest as
aggressive notifications, forced attention, or behavior that prioritizes
engagement metrics over user agency.

A Balance to Strike: Respect for User Agency: Software should respect the
user's environment, adhering to the conventions and behaviors of their chosen
window manager or desktop environment.  Customizability: Allow users to opt
into enhanced behaviors if they align with their needs, but never force them.
Transparency and Privacy: Application behavior should be clear, and its
intentions (including data usage) should be upfront, giving users confidence in
its purpose.  In short, well-designed software empowers the user rather than
dictating terms, contributing to a healthier digital ecosystem.

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

#276033 — Who's the window manager's boss? [was: Firefox and XFCE]

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 26, 2024 at 04:11:49PM -0000, Frank Jezzer wrote:

[...]

> The tension between application-driven window management and user-driven window
> management is a microcosm of broader debates about control, autonomy, and the
> influence of external forces in our digital lives.

[...]

> In short, well-designed software empowers the user rather than
> dictating terms, contributing to a healthier digital ecosystem.

I agree on most points -- just where you write "the developer", I'd
write "the developer's boss" or even "the developer's boss's boss".

And those have an agenda where user empowerment isn't on the menu,
quite the contrary.

Cheers
-- 
t

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

#276039 — Re: Who's the window manager's boss? [was: Firefox and XFCE]

Hi,

On Fri, Dec 27, 2024 at 12:09:23AM +0100, tomas@tuxteam.de wrote:
> On Thu, Dec 26, 2024 at 04:11:49PM -0000, Frank Jezzer wrote:
> > In short, well-designed software empowers the user rather than
> > dictating terms, contributing to a healthier digital ecosystem.
> 
> I agree on most points -- just where you write "the developer", I'd
> write "the developer's boss" or even "the developer's boss's boss".

Not to worry; none of Frank's posts are written by a human, and some of
them contain hallucinated shell scripts that will never work.

Frank's already decided who their boss is.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#276041 — Re: Who's the window manager's boss? [was: Firefox and XFCE]

On 2024-12-27, Andy Smith <andy@strugglers.net> wrote:
> Hi,
>
> On Fri, Dec 27, 2024 at 12:09:23AM +0100, tomas@tuxteam.de wrote:
>> On Thu, Dec 26, 2024 at 04:11:49PM -0000, Frank Jezzer wrote:
>> > In short, well-designed software empowers the user rather than
>> > dictating terms, contributing to a healthier digital ecosystem.
>> 
>> I agree on most points -- just where you write "the developer", I'd
>> write "the developer's boss" or even "the developer's boss's boss".
>
> Not to worry; none of Frank's posts are written by a human, and some of
> them contain hallucinated shell scripts that will never work.

An hallucination is a perception without an object, which is closer to
describing the vocabulary of your conceit than my eventually erroneous shell
scripts.

As to who is the boss in your case, it's obvious it has always been your
finicky and ultimately ludicrous superego, always at the ready to veer
superciliously off-topic and suppress the primitive motives of that part of
yourself of which you remain blithely unaware. 

Main enfin.

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

#276046 — Re: Who's the window manager's boss? [was: Firefox and XFCE]

Hello,

On Fri, Dec 27, 2024 at 04:11:48PM -0000, Frank Jezzer wrote:
> On 2024-12-27, Andy Smith <andy@strugglers.net> wrote:
> > Not to worry; none of Frank's posts are written by a human, and some of
> > them contain hallucinated shell scripts that will never work.
> 
> An hallucination is a perception without an object, which is closer to
> describing the vocabulary of your conceit than my eventually erroneous shell
> scripts.

I think the main difference though is that no one is going to mistakenly
try to put the vocabulary of my conceit in to their computer expecting it
to work, whereas your LLM's hallucinated nonsense shell scripts will
remain in the archives of this list and in search results forever, a net
negative to the world.

Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#276048 — Re: Who's the window manager's boss? [was: Firefox and XFCE]

On 2024-12-27, Andy Smith <andy@strugglers.net> wrote:

>> An hallucination is a perception without an object, which is closer to
>> describing the vocabulary of your conceit than my eventually erroneous shell
>> scripts.
>
> I think the main difference though is that no one is going to mistakenly
> try to put the vocabulary of my conceit in to their computer expecting it

There are those of us who value humanity with all its foibles and mistaken
identities above the hallucinated disasters of your hypothetical machine, and
here, despite yourself, you demonstrate with your habitual blind vigor where
your true allegiances lie.

> to work, whereas your LLM's hallucinated nonsense shell scripts will
> remain in the archives of this list and in search results forever, a net
> negative to the world.
>
> Andy
>

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

#276018

On Thursday, 26 December 2024 00:10:47 -03 Max Nikulin wrote:
> On 25/12/2024 14:11, keller.steve@gmx.de wrote:
> > Max Nikulin writes:
> >> does switching between regular window title and
> >> client-side decorations changes anything? (right click menu for
> >> toolbar, "customize toolbar")
> >
> > That was exactly it.  It fixed the
> > unwanted raising of firefox's windows and also stops firefox from
> > doing its own title bars with different buttons (e.g. no "Roll Up").
>
> You may try to search for mozilla, window manager (fvwm?), gtk bugs or
> discussions related to client-side decoration and rising on click.
> Are there other applications that use CSD and behave in a similar
> way?

Hi,
I found Zotero and the Telegram-Desktop client behave in the same way.
There does not seem to be a setup pertaining to that behaviour for those
applications.
In my case on KDE 24 and Sid.
All the best
--
Eike Lantzsch KY4PZ / ZP5CGE

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

#276036

On 26/12/2024 16:42, Eike Lantzsch ZP5CGE / KY4PZ wrote:
> On Thursday, 26 December 2024 00:10:47 -03 Max Nikulin wrote:
>> You may try to search for mozilla, window manager (fvwm?), gtk bugs or
>> discussions related to client-side decoration and rising on click.
>> Are there other applications that use CSD and behave in a similar
>> way?
> 
> I found Zotero and the Telegram-Desktop client behave in the same way.
> There does not seem to be a setup pertaining to that behaviour for those
> applications.
> In my case on KDE 24 and Sid.

Perhaps I stripped too much context. The original complain is windows 
raising on mouse click despite the window is configured to not do so. I 
expect that it is not a wide spread configuration.

The question is whether applications that use client style decoration 
may query the window manager for similar user preferences and to respect 
them. So it may be a bug of specific applications, of a GUI toolkit, or 
some feature missed in the window manager.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web