[worklog] A week with pretty funny bugs

From the window the shadow of the matsu (松) on the curtain, this monday morning and the in the back of the neighbor's garden, the orange color of the mikan (ミカン). Tune for this week: Kodo - "O-Daiko"

Webcompat Life

• I created an index page for the previous worklogs, accessible from the menu. So it becomes easier to follow. This is the 8th edition of this worklog and so far, I'm trying to keep it going. We will see where it goes. It's an experiment.
• I really need to better understand httparchive so I can create queries for it. I did one 2 weeks ago for HTTP Refresh, but it was really a dumb one.
• Filed a feature request for a dependency graph in developer tools showing the HTTP requests. It is useful to know what has requested what and when in the process of debugging. The current cascade view is only a timeline view.
• Did a re-evaluation about the bugs status for Add-ons and E10s. The ball is either in the camp of add-on team or in the camp of add-on developer. Nothing we can do.
• We had a WebCompat meeting.

Firefox Bugs

• Last week, I mentionned about Bug 812899 which had an implementation difference with Chrome.
  Boris Zbarsky finished the part I was not comfortable with. Cool! It's now on the inbound.
• Firefox for Android doesn't work with about:config?filter=foo

Webcompat issues

(a selection of some of the bugs worked on this week).

• SMH is an Australian newspaper, which was not detecting Firefox Android because of their detection script. They upgraded the script they are using for device detection. They changed from "^Mozilla/5.0.*Android [1-3].*" to '^Mozilla/5.0.*Android.*Mobile.*'. This is fixing the issue. I would have preferred they moved to my suggestion in the comment.
• Nezu museum got rid of Sencha and now the site is compatible with more browsers.
• deceuu fixed because of a Firefox bug.
• Japanese website Belle Maison issue "fixed" by the webkit aliasing
• On ponpare Web site, we have a persisting issue even with layout.css.prefixes.webkit; true. I tried to dig a bit more into it. It led me to create a codepen with different configuration of CSS. The rendering is different depending on Safari (WebKit) and Firefox (Gecko). Specifically when there is a background image, Safari seems to drop the button appearance. Added a comment to the issue on the "compat spec" spec issues list and I ended up opening an issue on Gecko.
• OK Cupid is being partially fixed by layout.css.prefixes.webkit; true. There are remaining issues related to touch event and sliding of the central image. I pushed back in needsdiagnosis. Mike found and it's ugly. It fails because of H.caroInner.style["-webkit-transform"] = "translate3d(" + n + "px,0,0)". Mike filed a bug on Gecko.
• On Shiseido Japan website, there is an interesting bug about icons not being displayed. They use a piece of JavaScript to query a RSS feed and extract the name of the image used in the HTML. The var imagePath=thisObj.baseImagePath+$(this).find("icon").text(); The icon here is in fact <shiseido:icon… in the feed. As hallvord mentioned, the code should be rewritten to not rely on jQuery's find but call getElementsByTagNameNS(). The issue? It is working on Blink and Safari but not in Firefox. A bug had been opened on WhatWG spec but it has been closed. Outreach seems the only way forward.
• In Japan, there are at least two sites, Tokyo Metro and CircleSunkus which depend on the zoom property. This property is an IE-ism which was retrofitted into WebKit for Compatibility reasons, then made its way to Blink and because Firefox doesn't implement it, so we have Web compatibility issues. Microsoft has a rough draft about the property. It was discussed in May 2015 by the CSSWG. I sent an email to the CSS WG with the data.
• Another funny issue on the ESA site (European Space Agency) and for once not a Web Compatibility issue, just a strange choice. They send users to the mobile site if their window is 1016px or less. if (d == 1 || (d == -1 && window.innerWidth < 1017)) window.location = 'http://m.esa.int/ESA'; It's a very strange strategy.

Webcompat.com development

• When doing bugs triage and work, I noticed a couple of things monday morning. I filed 3 issues but I hope it might be a caching issue on my side. Let's see: 913, 914, 915. Guillaume has already fixed 914.
• Starting to update a couple of modules for the project and issued a pull request for it.
• Spent quite a bit of time wrapping my head around the tests fixtures for completing the tests of our webcompat API. Not totally there yet. I guess a good opportunity for documenting.

Reading List

Follow Your Nose

• Document how to write tests on webcompat.com using test fixtures.

Otsukare!