Opened 7 years ago

Closed 7 years ago

#14419 closed defect (fixed)

mobile ListItem widget is not creating the proper element type LI

Reported by: Carlos Santana Owned by: ykami
Priority: high Milestone: 1.7.1
Component: DojoX Mobile Version: 1.7.0
Keywords: mobile Cc: csantana@…
Blocked By: Blocking:

Description

mobile ListItem? widget is not creating the proper element type LI Its working on dojo 1.6.1 not working on dojo 1.7.0 onClick function assumes LI is present when anchorLabel is true It goes into infinite loop, there is a for loop that is set to stop when p.parentNode.tagName !== "LI"

Another problem, people have implemented styling based on "LI" and the css will no longer work

to reproduce here is some code: <!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no"/> <meta name="apple-mobile-web-app-capable" content="yes" /> <script type="text/javascript" src="../dojosrc/dojo/dojo.js"></script> <script type="text/javascript">

dojo.ready(function(){

dojo.require("dojox.mobile"); dojo.require("dojox.mobile.deviceTheme"); dojo.requireIf(!dojo.isWebKit,"dojox.mobile.compat"); dojo.require("dojox.mobile.View"); dojo.require("dojox.mobile.RoundRectList?"); dojo.require("dojox.mobile.ListItem?");

var view = new dojox.mobile.View({id:"view0",selected: true},dojo.create("div", null, dojo.body())); view.startup(); view.show(); var ul = new dojox.mobile.RoundRectList?({id:"ul0"}); var li = new dojox.mobile.ListItem?({id:"id0",

label:"label", anchorLabel: true, clickable: true});

ul.addChild(li); view.addChild(ul); li.startup();

});

</script>

</head> <body> </body> </html>

If you inspect the Dom you don't get a <li></li> element <div id="view0">

<ul id="ul0">

<div id=li0"> </div>

</ul>

</div>

If you try to click on the list item outside the element with class mblListItemTextBox, like the arrow on the right you get error about the infinite loop on the Console: TypeError?: 'null' is not an object (evaluating 'p.tagName')

two suggested changes mobile.ListItem?.js and mobile._ItemBase.js:

ListItem?.js: Don't do the cheek explicit on string "LI" do it on li node tagName based on event

for(var p = e.target; p.tagName !== LI ; p = p.parentNode){…

it should be

for(var p = e.target; p.tagName !== li.tagName ; p = p.parentNode){...

_ItemBase.js: add the function buildRendering to create LI

buildRendering: function(){

this.domNode = this.containerNode = this.srcNodeRef
win.doc.createElement("LI");

},

need to require "dojo/_base/window" and associate with "win" , in the define line

Change History (4)

comment:1 Changed 7 years ago by Carlos Santana

I aware that this is not broken in all cases. The problem only happens when you create a widget with no srcNode passed and then place it on the dom. I'm not using parseonLoad, my App starts with an empty body, everything is manage and created using dojo/js

There are two workarounds:

  1. Using parser or template

<li id="li0" dojoType="dojox.mobile.ListItem?" anchorLabel="true" clickable="true"> label </li>

  1. creating the li Node first, then using it as srcNode to new ListItem?

liNode = dojo.create("LI",null,ul); li = new dojox.mobile.ListItem?({id:"id0",

label:"label", anchorLabel: true, clickable: true},

liNode);

I hope it helps others. Maybe some are getting the error on the console and can't tell why this is showing up in Dojo 1.7 TypeError??: 'null' is not an object (evaluating 'p.tagName')

comment:2 Changed 7 years ago by ykami

In [27347]:

Refs #14419 !strict. When ListItem? is created programmatically, use LI tag instead of DIV tag as domNode. Also added the 'tag' property in case someone want to choose what tag to use.

comment:3 Changed 7 years ago by ykami

In [27348]:

Refs #14419 !strict. When ListItem? is created programmatically, use LI tag instead of DIV tag as domNode. Also added the 'tag' property in case someone want to choose what tag to use.

comment:4 Changed 7 years ago by ykami

Milestone: 1.7.1
Resolution: fixed
Status: newclosed

Thank you for finding this, and for your suggestion. You are correct. It looks a bit critical and the fix is trivial, so I also back-ported it to the 1.7 branch.

Note: See TracTickets for help on using tickets.