Loading…
[Firefox] Block element not work properly on some sites #810
6 participants
"Going busy": by design. You have to move the move to the lower right to bring forth the dialog box where you will finalize your filter choice.
Yes, I was confused by this behavior too, until I saw gorhill/uBlock#803.
If you mistakenly pick the whole page, the pink overlay makes the dialog so subtle that I missed it completely, and the hourglass made it appear as an unresponsive page.
Easily reproduced right here on github, right click -> block element on any lateral "white empty space".
Okay, I think I undestand now the description. uBlock won't allow you to select the html or body element of a page. So if there is nothing where you right-click, it won't select anything. uBlock can't know whether there is anything where you right-click before you access the element picker. So this may happen if you right click where there is nothing: no element can be found to highlight.
By design.
So if there is nothing where you right-click, it won't select anything.
But it is selecting 'something'.
I don't think the problem is the functionality, but how the graphic design (colors, transparency, etc) of the element picking process can be confusing on certain pages. Like I said, this very page is a fine example, while in NYTimes front page won't let you select such a wide scope.
Here a screenshot, notice how the dialog might be easily missed in this relatively clean page:
@Mikey1993 But in this case there is no outside area to click to dismiss the element picker, as the whole containing div is been highlighted. So I think the dialog needs to standout somehow.
Once you know is there you won't miss it again, but for new users can be (is) confusing.
@alejandrolemus No, the state of the page that is shown here is after the element has already been selected and the cursor is in its "loading" state, which means that the Element Picker is waiting for user input.
The pink area is just the selected area by the Element Picker, as it can also be counted to be an outside area exterior to the dialog, therefore an area to click on to exit the Element Picker.
In any case, I strongly agree that the dialog needs to standout as mentioned above.
the element has already been selected
@Mikey1993 Oh yes, I see your point now. To put it another way, the dialog is too transparent even when the user already picked an element and the next logical step would be to modify/accept rule in that same dialog. So the dialog should be fairly noticeable at that point.
therefore an area to click on to exit the Element Picker
That, or the dialog should be less transparent to begin with. If that level of transparency is a must for some reason even after picking the element, then I would suggest that clicking "inside" an already picked element would have the dialog flash or standout, grabbing the user's attention.
the dialog is too transparent
There could be an element highlighted behind the dialog, and the user must have a way to know this. So the current way is to move the mouse cursor outside the dialog to reveal whether there is a highlighted element behind the dialog box.
Learning that the mouse has to be over the dialog is a one-time thing, but learning whether an element is highlighted behind the dialog box is something which always come up when using the element picker.
Well then, there are two opposite scenarios with benefits/issues, and is just a matter of deciding which one to favor.
clicking "inside" an already picked element would have the dialog flash or standout
Or this ^, or any of those nice suggestions Mikey made :)
I admit, I found it very confusing too. Particularly as the "busy" cursor is generally used to indicate that you should wait, not that you should be looking for other UI. I click Block Element, the cursor goes busy, so I wait for the element to be blocked. When it isn't, I assume it's stalled!
Another suggestion for a UI for this, if you are interested in re-working the area:
- Do not use the busy cursor at all, unless you really are temporarily busy and the user should wait. If you want a cursor to indicate the inactive state of the page, then the not-allowed cursor would be more appropriate - however if following the advice that clicking in the dimmed area outside the picked element should simply cancel, then no special cursor is needed at all.
- Place the UI next to the element being blocked (of course subject to the limitations of a minimum width and being within the window frame), but it should not be hidden off in the corner. Most often the user will likely only want to confirm the blocking, so it could be simplified down in a default view with a button to drop down the more advanced panel to choose alternative filter suggestions:
@AlexVallat I like your redesigned element picker dialog. Is there any way to test it ?
@Snapy Thank you. I'm afraid not, though, it is just a design mock-up, not a working implementation.
When I right click on some sites and choose 'Block element' from context menu, it's select the whole page or part of it (its depend where I right click) and going to be busy. The only way to cancel this, is to press Esc button from the keyboard or click on Quit in popup window. If I click on Pick in popup window I can choose what to block. Element blocking work correct when it is selected from uBlock popup window.
For example when I right click in most left on https://github.com/gorhill/uBlock/releases it select the whole page and going to be busy. When I right click on some text, it's select the line with the text and going to be busy.
For example when I right click in most left on https://support.mozilla.org/en-US/kb/Live%20Bookmarks I can choose element without problems, but when I right click on some text it's again select the line with the text and going to be busy.
I'm not sure how it work in Google Chrome.
My Firefox is 35.0.1 on Windows 7 x64