Tag: javascript

RFC 6225 Geolocation configuration generator tool

While mobile devices (especially those with a GPS) have made people more aware of geolocation/geotagging, you don’t need a GPS in a device to make it location-aware, nor do you need to resort to IP-based reverse lookups. Location information can be made available on any network that has a DHCP server using the Location Configuration Information DHCP Option defined in RFC 3825 and RFC 6225. It makes sense: for most wired or wireless networks, the engineer responsible for setting up the DHCP server will know at the least where the server or AP is located, and maybe even static information about the locations of each terminal of a wired port.

The Option has a somewhat unorthodox binary format with non-power-of-2-width fixed point reals. To make generating the DHCP configuration statements easier, I developed a web-based RFC 6225 location configuration generation tool. It’s all client-side and even has a Google Maps preview of the location!

Copy the configuration to your local DHCP server, grab an appropriate geolocation library, and you’re ready to go! The tool generates a DHCP LCI Option for both dnsmasq and ISC’s dhcpd.

The lack of fixed point integers in Javascript made the implementation a little trickier than it would have been in, say, C.

Other lessons: Google Maps is not highly accurate.

Update 2019-06-01: updated the tool from RFC 3825 to support RFC 6225 and the GeoLoc option.
Update 2023-04-24: fixed a bug with the dhcpd/dnsmasq config lines missing the leading payload bytes (that existed since 2019 :( )

Firefox NS_ERROR_INVALID_POINTER with innerHTML

When trying to use prettify here on Defective Semantics I ran into problems with firefox. Here are the errors from the error console:

Error: undefined entity
Error: uncaught exception: [Exception...
 "Component returned failure code: 0x80004003 
 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLElement.innerHTML]"  
  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"
  location: "JS frame :: hxxp://example.net/prettify.js :: 
             replaceWithPrettyPrintedHtml :: line 1414"
  data: no]

My insistence on trying to use XHTML on the blog is partly to blame. Prettify tries to add “ ” entities to the source (even if it’s a pre element) to appease Internet Explorer. This entity only semi-works in XHTML: I’ve run into similar problems with some HTML entities not being loaded, because some browsers don’t load the DTD (which in turn loads the entity sets). It also appears that while Firefox claims to support HTML latin 1 entities in a document with a PUBLIC XHTML identifier, it doesn’t actually reparse innerHTML assignments according to those rules.

My solution is to add a conditional test for XML. Having a look at the Javascript document object there doesn’t seem to be a reliable way to detect whether the browser is treating the document as XML from javascript. My best attempt was:

document.xmlVersion && (document.compatMode=='CSS1Compat');

which works for Firefox and Opera.

As a separate issue, Chrome and Safari (and presumably anything WebKit based) don’t allow assignment of innerHTML for XML documents, giving NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7.
Fixing prettify to use only DOM methods instead of building up a string and assigning it to innerHTML could be a lot of work. At least this exception, unlike the Firefox error, doesn’t leave the pretty-printed block in an inconsistent state.

I submitted a patch to the prettify issue tracker.