ClickShortCut on invisible buttons

Hi,

I have a button with a ClickShortcut:


    Button buttonWithShortCut = new Button("ButtonWithShortCut");
    buttonWithShortCut.setClickShortcut(KeyCode.ENTER);
    buttonWithShortCut.addClickListener(new Button.ClickListener() {

      @Override
      public void buttonClick(ClickEvent event) {
        System.out.println("buttonWithShortCut clicked");
      }
    });

When I set the button to invisible (buttonWithShortCut.setVisible(false):wink: the ClickShortcut still triggers the buttonClick mehtod.

Is this a bug or a feature?

Thanks a lot!

Any ideas?

We see an even odder problem with these. If we have multiple TABs, and one of the TABs has a click shortcut for ENTER on it, pressing ENTER in another TAB will also fire that event, blocking the ENTER on the TAB where it’s typed and firing in the TAB that’s not even visible.

We are using 7.1.7.

Wanted to add that this also occurs on the recent versions of Chrome, Firefox, IE, Safari and Opera, so it’s not browser-specific at all.

Also, sometimes a TAB has other hidden area (like an entire form to appears only after a row is selected from a table) that contains this click shortcut, and so it’s fired and generally results in null pointer exceptions and such in our code because the page is not really supposed to have to deal with input on hidden parts of the UI.

It appears that something is very wrong – and makes me think that Vaadin 7.1.7 is potentially very insecure as input is not being validated correctly and is being routed to hidden UI elements. This is a serious vulnerability it would seem and hope it can be addressed quickly.

Currently, my only solution is to remove all shortcuts, but this doesn’t mean there are related issues with processing input that it shouldn’t be processing without any validation/integrity checking taking place.

Another update that this appears to happen back to 7.1.0 as well. I tried to go back to 7.0.7, but there were too many structural changes in our code as it relates to Vaadin that would also have to be rolled back to make it work.

This is a serious vulnerability because it implies that input is not be validated and routed correctly, and it means that handlers are not correct in that a button that is not even visible is trying to handle being clicked. If it’s just a default key handler, it’s bad enough as it means that buttons the user may not have permission to can be fired (because they are not even visible). We are most concerned about what other non-validation and mis-routing may be taking place since a key benefit of Vaadin was that it was supposed to ensure such input validation to avoid such a potential security exploit.

Cross reference to ticket 12743: http://dev.vaadin.com/ticket/12743

It’s possible this is an old bug that we reported back in the Vaadin 6.6 days on ticket 7122: http://dev.vaadin.com/ticket/7122