3 Replies Latest reply on Jan 2, 2015 11:44 AM by Jacques Marzin

    Curious js behaviour : already found ?

    Jacques Marzin

      I built the smallest app exposing a curious behaviour wiht js managing in a ruby app : On the main screnn, I design a button with an onclick js function that modifies html in a div. No problem with that screen.

      I create a small model. On the main screen, I put a link to the index action of the new controller. There's the curious sequence :

      • Launch the app
      • Click on button : it works
      • Click on the link
      • On the new page, click on Home
      • Click on buttton : again : it doesn't work !

      When you look in the source debugging js on the fly, one can see that the html have been modified, but not in the document displayed.


      Here's the link to my app in github https://github.com/jmarzin/essai_js_rhomobile

        • Re: Curious js behaviour : already found ?
          Kutir Mobility

          Hi Jacques ,

          We will try it locally and get back to you.


          Visnupriya R

          Kutir Mobility

            • Re: Curious js behaviour : already found ?
              Jon Tara

              You have a duplicate ID.


              You really should NEVER use IDs when using jQuery Mobile. This is a good illustration of the problem. It is hard to avoid duplicates, even if you think you have.


              JQM keeps the first page ever loaded in the DOM. That's index.html. Now, when you load a NEW copy of index,html, you have TWO - the original (which never goes away) and the one you just loaded.


              Duplicate IDs are not valid HTML, and so the browser does the best it can with a bad situation. MOST browsers when asked to select an ID that has duplicates will return the FIRST. That's the one on the initial page, not the new one that is shown.


              I see you will have a problem as well in your model. If you navigate from one instance directly to another of the model object, then you will have a duplicate ID. That's because when JQM does a page transition, both pages have to be in the DOM at the same time. (Once the new page is fully loaded, the old one is THEN discarded. Unfortunately, during page initialization, both pages are present, and ID selectors will fail to do as expected.)


              Best practice is to not use IDs. Use CSS classes, and then limit query scope to a particular page. In many cases, all that is needed is to limit query scope to the CURRENT page, e.g.:  (if you want to affect some specific page or pages, add a class to those pages, and use that class instead of ui-page);


              $(document).on('pageinit', '.ui-page', function() {
              var $page = $(this);
              var $btn = $page.find('.some-css-class');
              // Now do something with $btn, maybe register for clicks
              $btn.on('click', function(....


              A couple of best practices:


              - Never use Javascript alert() for debugging. It blocks the browser, which can break some of your JS code, and even mysteriously make "broken" JS code work!


              - Never use old-fashioned inline Javascript (e.g. onclick, etc.) Write JS to register for a callback.


              Best advice: stop using IDs NOW, before the project gets too big. I have done several "rescues" on ID-ridden JQM projects, and it can be a considerable effort to fix one you have a large app. Like, several weeks of work!


              It is sometimes hard to notice or diagnose, because it is often dependent on the user's navigation path. A project might get built-out to quite some extent before anybody notices that strange things are happening. It's probably the most insidious JQM "gotcha".

            • Re: Curious js behaviour : already found ?
              Jacques Marzin

              Thanks a lot ! Understood ! I will never use Ids again...