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

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

Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value.

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

Contents

  Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-21 12:39 +0100
    Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-22 00:05 +0100
      Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-22 08:59 +0100
        Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. Flng Fck <nothanks@invalid.invalid> - 2019-02-22 09:05 +0100
          Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-22 10:50 +0100
    Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. Joao Rodrigues <jr.c.l.js@gmail.com> - 2019-02-21 21:51 -0300
      Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-22 09:29 +0100
    Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. JJ <jj4public@vfemail.net> - 2019-02-22 18:49 +0700
      Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-22 13:51 +0100
        Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. Update. "R.Wieser" <address@not.available> - 2019-02-22 14:34 +0100
          Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value.Solved. "R.Wieser" <address@not.available> - 2019-02-22 15:12 +0100
        Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. JJ <jj4public@vfemail.net> - 2019-02-23 10:18 +0700
          Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-23 09:53 +0100
            Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. JJ <jj4public@vfemail.net> - 2019-02-23 18:14 +0700
              Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. "R.Wieser" <address@not.available> - 2019-02-25 18:53 +0100
                Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-26 10:23 +0100
                  Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-26 11:27 +0100
                    Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-26 12:54 +0100
                      Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-26 19:26 +0100
                        Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-27 10:45 +0100
                          Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-27 12:09 +0100
                            Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-27 12:34 +0100
                              Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-28 11:07 +0100
                                Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-28 12:46 +0100
                                  Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-02-28 22:41 +0100
                                    Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-03-01 09:59 +0100
                                      Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-03-01 10:55 +0100
                                        Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-03-01 11:40 +0100
                                          Re: Greasemonkey vs the other ones - iframes "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-03-01 16:08 +0100
                  Re: Greasemonkey vs the other ones - iframes JJ <jj4public@vfemail.net> - 2019-02-27 00:12 +0700
                    Re: Greasemonkey vs the other ones - iframes "R.Wieser" <address@not.available> - 2019-02-27 10:39 +0100

Page 1 of 2  [1] 2  Next page →

#36041 — Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value.

Hello all,

I do not see a GreaseMonkey specific newsgroup, so I'm posting here as the 
next-best thing.

The problem: I'm using FireFox 52, and am trying to find elements with the 
'position' is 'fixed' settings (yes, stuff stuck to the top or bottom of my 
screen.  I want to un-stick them).

For that I'm using the following line :

  if (window.getComputedStyle(aElements[i]).getPropertyValue("position") == 
'fixed') {

But for some reason it doesn't find elements which are floating, but when 
use "inspect element" -> "rules" it does actually show a position: fixed 
entry.

I did try to execute that above line on a mouse-click event, but it didn't 
find the element than either (indicating that it doesn't seem to be a "DOM 
must be fully loaded first" problem).

Does someone here have an idea of what goes wrong and how to fix it ?

And by the way, this is a site on which it fails.  For both the purple top 
bar and the green block on the left: 
https://sourcemaking.com/design-patterns-and-tips

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#36042

"R.Wieser" <address@not.available> wrote on 21 Feb 2019 in
comp.lang.javascript: 

> Hello all,
> 
> I do not see a GreaseMonkey specific newsgroup, so I'm posting here as
> the next-best thing.
> 
> The problem: I'm using FireFox 52, and am trying to find elements with
> the 'position' is 'fixed' settings (yes, stuff stuck to the top or
> bottom of my screen.  I want to un-stick them).
> 
> For that I'm using the following line :
> 
>   if (window.getComputedStyle(aElements[i]).getPropertyValue("position")
>   == 'fixed') {
> 
> But for some reason it doesn't find elements which are floating, but

'fixed' is not the same as 'floating'.

Try using '.getPropertyValue':

===============
<div style='position:relative;'>first</div>
<div style='position:fixed;'>second</div>

<script>
  const x = document.querySelectorAll('div');

  for (let i=0; i<x.length; i++) {
     let y = window.getComputedStyle(x[i]);
     let z = y.getPropertyValue("position");
     if ( z == 'fixed' ) console.log('Found text: ', x[i].innerHTML );
  };
</script>
===============


> when use "inspect element" -> "rules" it does actually show a position:
> fixed entry.
> 
> I did try to execute that above line on a mouse-click event, but it
> didn't find the element than either (indicating that it doesn't seem to
> be a "DOM must be fully loaded first" problem).
> 
> Does someone here have an idea of what goes wrong and how to fix it ?
> 
> And by the way, this is a site on which it fails.  For both the purple
> top bar and the green block on the left: 
> https://sourcemaking.com/design-patterns-and-tips
> 
> Regards,
> Rudy Wieser
> 
> 
> 



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

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

#36044

Evertjan,

> 'fixed' is not the same as 'floating'.

I did not say it was.   And it looks like I've provided you with /another/ 
method to make an element stick somewhere. :-)

> Try using '.getPropertyValue':

You obviously didn't even read what I wrote  :-((

All your code does is using three lines which do /exactly/ what my posted 
single line does.

Regards,
Rudy Wieser

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

#36045

Il 22/02/2019 08:59, R.Wieser ha scritto:
>> 'fixed' is not the same as 'floating'.
> I did not say it was.


Don't bother, he's always assuming people are stupid

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

#36047

Flng Fck,

> Don't bother, he's always assuming people are stupid

Which isn't a too-bad assumption to /begin/ with. :-)

... but should be followed up with an assessment of the others level of 
stupidity - or lack thereof.

There are quite a few stories on "tha intarwebz" about highy-trained people 
which need "dumb worker drones" to point out that a powercord extension 
plugged into its own block will not provide the other powercords in that 
same block with anything.     Or doctors who disconnect the ethernet cable 
from their 'puters (so they can sit somewhere else) not understanding why 
they can't connect to the intranet anymore (and even worse: do not link 
their earlier actions with that loss of connectivity)

In other words, even /intelligent/ people can have their "dubm" moments. :-)

Regards,
Rudy Wieser

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

#36043

On 21/02/2019 08:39, R.Wieser wrote:
> Hello all,
> 
> I do not see a GreaseMonkey specific newsgroup, so I'm posting here as the
> next-best thing.
> 
> The problem: I'm using FireFox 52, and am trying to find elements with the
> 'position' is 'fixed' settings (yes, stuff stuck to the top or bottom of my
> screen.  I want to un-stick them).

Jeez, FF 52 is a bit dated now. If I recall correctly, I think even that 
version already supported position 'fixed' and 'sticky' for instance.

> 
> For that I'm using the following line :
> 
>    if (window.getComputedStyle(aElements[i]).getPropertyValue("position") ==
> 'fixed') {

Maybe the problem happens with the Array of elements -> aElements[i]. Or 
maybe the 'fixed' element lacks a 'top: 0' (distance in pixels from the 
top of the document). But that's just guessing.

> 
> But for some reason it doesn't find elements which are floating, but when
> use "inspect element" -> "rules" it does actually show a position: fixed
> entry.
> 
> I did try to execute that above line on a mouse-click event, but it didn't
> find the element than either (indicating that it doesn't seem to be a "DOM
> must be fully loaded first" problem).

I doesn't seem to be that sort of problem.

> 
> Does someone here have an idea of what goes wrong and how to fix it ?
> 
> And by the way, this is a site on which it fails.  For both the purple top
> bar and the green block on the left:
> https://sourcemaking.com/design-patterns-and-tips
> 

The following snippet returned 'fixed' in my FF 65.0.1 on Win10:

const nav = document.querySelector('body > 
div.announcement-block.prom.ga-triggered');
console.log(window.getComputedStyle(nav, null).position); // fixed.

A while ago I've written a Codepen example to fix a menu bar at the top 
of the document, using a similar approach:
<https://codepen.io/jrio/pen/GWmMKN>

HTH

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

#36046

Joao,

> Jeez, FF 52 is a bit dated now.

What more do you know about FF 52 ?   Something that is rather specific to 
that version I mean ...

> Maybe the problem happens with the Array of elements -> aElements[i]

Problems such as ....?

> Or maybe the 'fixed' element lacks a 'top: 0'

How would that stop the line I posted from functioning correctly ?

> I doesn't seem to be that sort of problem.

Yes, that is what I tried to say there.


A remark though: I posted that line of code because /that/ one is not doing 
what its supposed to do.

How I know ?    Because I dumped, among others, the result of that 
"getPropertyValue" for /all/ elements into the debug console - and noticing 
that it shows, for the elements I mentioned, another result than what 
"inspect element" shows for them.

Regards,
Rudy Wieser

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

#36048

On Thu, 21 Feb 2019 12:39:54 +0100, R.Wieser wrote:
> Hello all,
> 
> I do not see a GreaseMonkey specific newsgroup, so I'm posting here as the 
> next-best thing.
> 
> The problem: I'm using FireFox 52, and am trying to find elements with the 
> 'position' is 'fixed' settings (yes, stuff stuck to the top or bottom of my 
> screen.  I want to un-stick them).
> 
> For that I'm using the following line :
> 
>   if (window.getComputedStyle(aElements[i]).getPropertyValue("position") == 
> 'fixed') {
> 
> But for some reason it doesn't find elements which are floating, but when 
> use "inspect element" -> "rules" it does actually show a position: fixed 
> entry.
> 
> I did try to execute that above line on a mouse-click event, but it didn't 
> find the element than either (indicating that it doesn't seem to be a "DOM 
> must be fully loaded first" problem).
> 
> Does someone here have an idea of what goes wrong and how to fix it ?
> 
> And by the way, this is a site on which it fails.  For both the purple top 
> bar and the green block on the left: 
> https://sourcemaking.com/design-patterns-and-tips
> 
> Regards,
> Rudy Wieser

Works fine from my FF52 ESR using below code.

  Array.from(document.all).forEach(
    function(ele) {
      var v = getComputedStyle(ele).getPropertyValue("position");
      if (v === "fixed") {
        console.log(ele.tagName, "/", ele.className, "/", ele.id);
      }
    }
  );

It outputs:

  DIV / announcement-block prom /
  ASIDE / sidebar main-menu nano /

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

#36049

JJ,

> Works fine from my FF52 ESR using below code.

I think I / GreaseMonkey really has got a problem. :-|

I ran your loop, without the "if" and with code a GreaseMonkey apropriate 
debug-output:

- - - - - - - - - - - -
  Array.from(document.all).forEach(
    function(ele) {
      var v = getComputedStyle(ele).getPropertyValue("position");
        GM_log(ele.tagName +"/"+ ele.className +"/"+ ele.id +"/"+ v );
    }
  );
- - - - - - - - - - - -

This is what I got for both "aside"s:

- - - - - - - - - - - -
ASIDE/feature content-secondary//static
ASIDE/sidebar main-menu nano//static
- - - - - - - - - - - -

When I (re)checked using FFs "inspect element" both showed a "fixed" 
position attribute - which does not match the above output. :-(

I forgot to mention it, but I'm using GreaseMonkey v3.17.

Regards,
Rudy Wieser

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

#36050 — Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value. Update.

When I add an addEventListener for "click", which runs my code, I do get the 
expected elements back:

ASIDE//sidebar main-menu nano/fixed
DIV//announcement-block prom/fixed

I have no real clue why it didn't work the first time I tried it (might have 
altered the condition on the mean time though).  But this reasult does seem 
to indicate that it might be related to asking for that CSS attribute too 
early (before the CSS is applied to the elements) ...

Regards,
Rudy Wieser

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

#36051 — Re: Greasemonkey getComputedStyle doesn't doesn't return the expected-and-confirmed value.Solved.

After it became clear that I, most likely, was asking for the CSS attributes 
to early the searching for the solution became /much/ easier. :-)

The implemented solution was to wait for the full page /and/ its resources 
(like CSS) to be loaded by using "addEventListener" with the "load" 
argument.   Currently I'm just changing the "position" to "static".  Lets 
see how well it works.

Regards,
Rudy Wieser

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

#36052

On Fri, 22 Feb 2019 13:51:51 +0100, R.Wieser wrote:
> JJ,
> 
>> Works fine from my FF52 ESR using below code.
> 
> I think I / GreaseMonkey really has got a problem. :-|
> 
> I ran your loop, without the "if" and with code a GreaseMonkey apropriate 
> debug-output:
> 
> - - - - - - - - - - - -
>   Array.from(document.all).forEach(
>     function(ele) {
>       var v = getComputedStyle(ele).getPropertyValue("position");
>         GM_log(ele.tagName +"/"+ ele.className +"/"+ ele.id +"/"+ v );
>     }
>   );
> - - - - - - - - - - - -
> 
> This is what I got for both "aside"s:
> 
> - - - - - - - - - - - -
> ASIDE/feature content-secondary//static
> ASIDE/sidebar main-menu nano//static
> - - - - - - - - - - - -
> 
> When I (re)checked using FFs "inspect element" both showed a "fixed" 
> position attribute - which does not match the above output. :-(
> 
> I forgot to mention it, but I'm using GreaseMonkey v3.17.
> 
> Regards,
> Rudy Wieser

I'm using TamperMonkey, BTW.

The GreaseMonkey addon, despite its officiality, is problematic, IME. And it
gets worse in its 4.x version. I'd rather use either TamperMonkey or
ViolentMonkey.

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

#36054

JJ,

> The GreaseMonkey addon, despite its officiality, is problematic, IME.
...
> I'd rather use either TamperMonkey or ViolentMonkey.

Could you give a bit more info here ?   I always assumed that TamperMonky 
was just a "my way or the high way" kind of spin-off, and I can't remember 
having ever heard of ViolentMonkey.

I've just done a quick-ish search for "GreaseMonkey vs TamperMonkey", but 
got nowhere in regard to a feature and/or problem comparision.    Do you 
maybe have an URL for me ?

Though on the positive side I found that ViolentMonkey is the open-source 
equivalent of TamperMonkey.

In short, what are the problems with GreaseMonkey (v3) for which I should 
ditch it in favour of either Tamper- or ViolentMonkey ?

Regards,
Rudy Wieser

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

#36055

On Sat, 23 Feb 2019 09:53:17 +0100, R.Wieser wrote:
> 
> Could you give a bit more info here ?   I always assumed that TamperMonky 
> was just a "my way or the high way" kind of spin-off, and I can't remember 
> having ever heard of ViolentMonkey.

ViolentMonkey was the only decent UserScript provider for Chrome (and Opera 
Presto, IIRC). There was no GreaseMonkey and TamperMonkey for Chrome back 
then.

> I've just done a quick-ish search for "GreaseMonkey vs TamperMonkey", but 
> got nowhere in regard to a feature and/or problem comparision.    Do you 
> maybe have an URL for me ?

No, sorry.

> Though on the positive side I found that ViolentMonkey is the open-source 
> equivalent of TamperMonkey.

You could say that. But neither ViolentMonkey and TamperMonkey tries to be a 
clone of the other. Both ViolentMonkey and TamperMonkey are clones of 
GreaseMonkey, and follows GreaseMonkey's UserScript specification. They have 
their own extra metadata, and support some of each others' extra metadata.

> In short, what are the problems with GreaseMonkey (v3) for which I should 
> ditch it in favour of either Tamper- or ViolentMonkey ?

Its sandbox specification is unclear. Sometimes we can modify a global 
object or element object, sometimes we can't for other object. e.g. add a 
new (custom) property, or modify an existing property. Even though the 
object is not sealed, or the property is not frozen. I mean, how the sandbox 
allow/disallow object modification, is unclear.

So, scripts which were made and tested as working on TamperMonkey or 
ViolentMonkey, may not work properly in GreaseMonkey. However, scripts which 
were made and tested as working on GreaseMonkey, are guaranteed to work 
properly in TamperMonkey and ViolentMonkey. All of these assuming that the 
scripts only use do not use TamperMonkey or ViolentMonkey specific features.

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

#36056

JJ,

Yikes, almost forgot to post a reply...

In short, the main difference is that GreaseMonkeys sandbox can, at times, 
be a bit wonky.  I'll keep that in mind for when I run into such problems 
(I'm currently not doing anything special. Just some cleaning up of the 
webpage. Ok, a /lot/ of cleaning up of certain webpages. :-) )

Thanks for the explanation.

Regards,
Rudy Wieser

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

#36057 — Re: Greasemonkey vs the other ones - iframes

JJ (and others),

I just realized I do have some kind of a "problem" with GreaseMonkey, and am 
wondering if either Tamper or ViolentMonkey does it differently.

GreaseMonkey seem to be starting to late to allow it to kill iframes : They 
can be removed from the DOM ofcourse, but the request for its contents has 
than already been send out. :-(

Do you (or anyone else reading this) know how that works for the others or 
how I can fix that for GreaseMonkey ?    If GreaseMonkey isn't up to it but 
either of the other two is it would certainly be a reason to consider 
switching.

(goes for other "early load" resources too ofcourse).

Regards,
Rudy Wieser

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

#36058 — Re: Greasemonkey vs the other ones - iframes

"R.Wieser" <address@not.available> wrote on 26 Feb 2019 in
comp.lang.javascript: 

> JJ (and others),
> 
> I just realized I do have some kind of a "problem" with GreaseMonkey,
> and am wondering if either Tamper or ViolentMonkey does it differently.
> 
> GreaseMonkey seem to be starting to late to allow it to kill iframes :
> They can be removed from the DOM ofcourse, but the request for its
> contents has than already been send out. :-(

How [with what code?] do/did you[!] kill an iframe,
before it has become alive? 

[I would call that abortion, btw.]

> Do you (or anyone else reading this) know how that works for the others
> or how I can fix that for GreaseMonkey ?    If GreaseMonkey isn't up to
> it but either of the other two is it would certainly be a reason to
> consider switching.
> 
> (goes for other "early load" resources too ofcourse).
> 
> Regards,
> Rudy Wieser
> 
> 
> 



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

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

#36059 — Re: Greasemonkey vs the other ones - iframes

Evertjan,

> How [with what code?] do/did you[!] kill an
> iframe,

var aElements = document.getElementsByTagName("iframe");
for (var i=aElements.length;i--;i>=0) {
        aElements[i].parentNode.removeChild(aElements[i]);
}

> before it has become alive?

Thats exactly the problem:  It happens /after/ it has become "alive" (read: 
the content for it has already been requested).

Regards,
Rudy Wieser

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

#36062 — Re: Greasemonkey vs the other ones - iframes

"R.Wieser" <address@not.available> wrote on 26 Feb 2019 in
comp.lang.javascript: 

> Evertjan,
> 
>> How [with what code?] do/did you[!] kill an
>> iframe,
> 
> var aElements = document.getElementsByTagName("iframe");
> for (var i=aElements.length;i--;i>=0) {
>         aElements[i].parentNode.removeChild(aElements[i]);
>}

Well, you can only do this AFTER the creation, 
so you should always be too late with any monkey, 
precluding serious monkey-bussiness.

>> before it has become alive?

Meaning only that the word "kill" seems ill-chosen.
 
> Thats exactly the problem:  It happens /after/ it has become "alive"
> (read: the content for it has already been requested).

So there is no question of simple abortion, isn't it?
 
> Regards,
> Rudy Wieser

====

I suppose you could request the content of the page as a string with some 
serverside or clientside Jasonery, and then, after deleting the iframes, 
innerHTML [cum <base href> insertion] the rest into a viewable page?

[but that forgoes the automatics of xmonkey.]





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

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

#36064 — Re: Greasemonkey vs the other ones - iframes

Evertjan,

> Well, you can only do this AFTER the creation,
> so you should always be too late with any monkey

Than why than can I "kill" images, scripts and CSS that way (no associated 
resources are requested) ?

> Meaning only that the word "kill" seems ill-chosen.

I do not see you giving a better one, so I'm going to ignore that.

> So there is no question of simple abortion, isn't it?

I have no idea.  That was why I posted my question.    Maybe one of the 
other plugins I mentioned does it differently and has no problem with it.

Regards,
Rudy Wieser

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web