Changes between Initial Version and Version 1 of Ticket #1431, comment 5


Ignore:
Timestamp:
09/24/2014 02:43:48 PM (5 years ago)
Author:
sebastian
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1431, comment 5

    initial v1  
    1010Given this isn't the first time users and testers reported issues that resulted from differences between the immediate feedback and actual result of using the "Block Element" option I'm convinced this is an issue we should address. 
    1111 
    12 > The solutions aren't great, other than reloading we might try to identify all elements affected by a rule (similar to how Element Hiding Helper does it with its preview feature) - but that's far from trivial, still error prone (e.g. if scripts are blocked) 
     12> The solutions aren't great, other than reloading we might try to identify all elements affected by a rule (similar to how Element Hiding Helper does it with its preview feature) 
    1313 
    1414I would be fine with that approach. Also note that we already generate a list of CSS selectors matching all affected elements, in order to highlight them while the "Block Element" dialog is shown. So it wouldn't be a big deal to go a step further and hide them all once the filter is saved. 
     15 
     16> but that's far from trivial, still error prone (e.g. if scripts are blocked) 
     17 
     18Scripts can't be selected with the mouse anyway, since they aren't visible. The only non-trivial case that currently comes to my mind is when the URL of an element affected by request blocking differs from its normalized form. But I think we can still make it work good enough.