2016 Challenge : Week #18

If you did not, read the initial blog post announcing the challenge

This week was a bit special as i’m now at the third of the project (and still on tracks !), and also because I just turned 31 today :) .

On Week #17 I started working on Bug 1245365, which described a bug in the markup panel search with attribute selector. I was waiting for review, which was granted on Monday, and the bug was resolved on Wednesday.

While waiting for review on the previous bug, I got my hands on Bug 1248274. There was an issue in the rule view: if you tried to click property value while editing the property name, the property value wasn’t being edited (the input was not displayed). This issue was only visible when the property value contained swatch elements (for colors, angle, …), which made me think that there should be something wrong due to some extra markup we don’t have for simple values. So what happened here ?

When the property name is being edited, losing focus (i.e. a blur event) will trigger a new computation of the property value. When the value is computed, the value container is cleared ( with innerHTML = ""). On another place, we listen to click events on the value container to know when to show the input to edit the value.

On regular values, the markup is pretty simple : we have a <span> as container, and the property value as its textContent :

<span
  xmlns="http://www.w3.org/1999/xhtml"
  class="ruleview-propertyvalue theme-fg-color1"
  tabindex="0">
    none
  </span>

For augmented values, we have a more complex markup, in order to show the swatch :

<span
  xmlns="http://www.w3.org/1999/xhtml"
  class="ruleview-propertyvalue theme-fg-color1"
  tabindex="0">
  <span data-color="#fff">
    <span
      class="ruleview-swatch ruleview-colorswatch"
      style="background-color:#fff">
    </span>
    <span class="ruleview-color">#fff</span>
  </span>
</span>

And that’s where lies the problem. When we are editing the propery name, if we click on the swatch for example, the blur event on the displayed input happened on the swatch’s span mousedown. On blur we then strip out the value container, and so the swatch span, which is the target of the mousedown, won’t capture the next mouseup event, and thus there won’t be a click event triggered. Which results in the property value input not being displayed.

So, that’s kind of ugly, but the solution does not seems prettier either. For now, I track the mousedown on the value container, and raise a boolean flag (hasPendingClick) that I then clear on click. So, if the value container gets updated, I check the flag, and if raised, I re-trigger a click event on the value container. I’m waiting for feedback on this because I’m really unsure of my solution.

During the week, I also got an email about a bug in the breadcrumb which appears in the markup panel. The bug was that the SVG element clipPath was displayed as clippath. This is wrong because non-HTML element should have a proper case, and it was somewhat related to a bug I fixed some times ago in the markup view. This made me think of all the places where we display tag names and after some research, I found that there were several modules, both client and server-side that suffer from this kind of issue. So I filed a bug (Bug 1270215), and there’s now an ongoing discussion on how we may fix this.

Like in previous weeks, I worked on the new React-based console frontend. There were just one of my pull request merged (Get data from the store using selectors on the reducer), but I worked on other issues I’ll talk about when they’re merged.

And that’s it for the week !