Wicket
  1. Wicket
  2. WICKET-1787

AjaxSubmitLink in Internet Explorer does not work with Wicket's automatically genreated id's

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3.5, 1.4-RC1
    • Component/s: None
    • Labels:
      None

      Description

      When using AjaxSubmitLink, and the markupid for a wicket element is not explicitly set, AjaxSubmitLink will not work with internet explorer. When clicking on your AjaxSubmitLink while running Internet Explorer, nothing will happen.

      Here is an example:
      html file:
      <img wicket:id="img_unlock" >

      java file:
      ContextImage unlockImage = new ContextImage("img_unlock", new Model("pathtoimage/unlockedgray.png"));

      Since the id attribute is not set, wicket will now generate the output id id="id". For some reason AjaxSubmitLink in Internet Explorer does not understand this (Firefox does). Here is the HTML output:

      <img class="ajaximg" src="../pathtoimage/unlockedgray.png" onClick="var wcall=wicketSubmitFormById('i3', '../?wicket:interface=:2:new_loancase:application_form:header:img_unlock::IActivePageBehaviorListener:0:1&wicket:ignoreIfNotActive=true', null,null,null, function()

      {return Wicket.$$(this)&&Wicket.$$('i3')}

      .bind(this));;"
      id="id">

      The solution is to explicit add the markupid, like this:
      unlockImage.setOutputMarkupId(true);
      unlockImage.setMarkupId("mynewdistinctid");

      Would it not be better if wicket automatically generated another name for the id attribute than "id"? Can this be done? Or is there a workaround I am not aware of?

        Activity

        Hide
        Asgaut Mjølne added a comment -
        Show
        Asgaut Mjølne added a comment - Here is someone who had the same problem, posted recently: http://www.nabble.com/Wicket-1.4m3---AjaxButton,-AjaxSubmitLink-in-ModalWindow-in-IE-7-Problem---td18912755.html
        Hide
        Igor Vaynberg added a comment -

        can you provide a quickstart please? looking at the code in component#getmarkupid(boolean) it looks like the id will always have a number appended to it, so wicket should never generate "id" id, but rather "id0" id...

        Show
        Igor Vaynberg added a comment - can you provide a quickstart please? looking at the code in component#getmarkupid(boolean) it looks like the id will always have a number appended to it, so wicket should never generate "id" id, but rather "id0" id...
        Hide
        Asgaut Mjølne added a comment -

        Before I provide a quickstart, I would like to mention that I am running Wicket version 1.3.3. Is this number appending something new in 1.3.4?

        Show
        Asgaut Mjølne added a comment - Before I provide a quickstart, I would like to mention that I am running Wicket version 1.3.3. Is this number appending something new in 1.3.4?
        Hide
        Igor Vaynberg added a comment -

        i am not sure, you should try 1.3.4 and the latest snapshot as well...

        Show
        Igor Vaynberg added a comment - i am not sure, you should try 1.3.4 and the latest snapshot as well...
        Hide
        Asgaut Mjølne added a comment -

        Checked the 1.3.4 code, the problem still remains.

        I debugged through the method:
        public String getMarkupId(boolean createIfDoesNotExist) in the class Component.java

        ...and found the bug. When Wicket executes this piece of code:
        String markupIdPostfix = Integer.toHexString(generatedMarkupId).toLowerCase();

        You will get "d" returned when 13 is the generatedMarkupId number. The method will then finally return "id" as the markupId!

        10 will return "a", 11 will return "b", 12 will return "c" and so on.

        Why do you hex the numbers?

        And how can we get around this? We are going into production with our web application and need a fix/workaround as soon as possible.

        Show
        Asgaut Mjølne added a comment - Checked the 1.3.4 code, the problem still remains. I debugged through the method: public String getMarkupId(boolean createIfDoesNotExist) in the class Component.java ...and found the bug. When Wicket executes this piece of code: String markupIdPostfix = Integer.toHexString(generatedMarkupId).toLowerCase(); You will get "d" returned when 13 is the generatedMarkupId number. The method will then finally return "id" as the markupId! 10 will return "a", 11 will return "b", 12 will return "c" and so on. Why do you hex the numbers? And how can we get around this? We are going into production with our web application and need a fix/workaround as soon as possible.
        Hide
        Igor Vaynberg added a comment -

        in 1.3 branch and trunk the prefix is "id" not "i" so this should no longer happen

        Show
        Igor Vaynberg added a comment - in 1.3 branch and trunk the prefix is "id" not "i" so this should no longer happen
        Hide
        Asgaut Mjølne added a comment -

        Okay, thanks. When is the release date for that fix? Currently our fix is to overwrite the Component class and remove the hexing. That worked.

        Could you tell me why you use the toHexString method please? Why not just convert the number over to a string? Is it just to avoid long numbers? Just curious.

        Show
        Asgaut Mjølne added a comment - Okay, thanks. When is the release date for that fix? Currently our fix is to overwrite the Component class and remove the hexing. That worked. Could you tell me why you use the toHexString method please? Why not just convert the number over to a string? Is it just to avoid long numbers? Just curious.
        Hide
        Igor Vaynberg added a comment -

        for a release date you should ask on the list

        re hexing: yes, it is to shorten the id values

        Show
        Igor Vaynberg added a comment - for a release date you should ask on the list re hexing: yes, it is to shorten the id values

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Asgaut Mjølne
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development