Closed Bug 796490 Opened 13 years ago Closed 8 years ago

B2G interprets POINT (PT) sizes incorrectly

Categories

(Firefox OS Graveyard :: Gaia, defect, P5)

Product:
Firefox OS Graveyard
Component:
Gaia
Type:
defect

Tracking

(blocking-basecamp:-, b2g18+)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-basecamp -
Tracking Flags:
Tracking Status
b2g18 + ---

People

(Reporter: ghtobz, Unassigned)

Details

(Whiteboard: visual design, flexible ui)

[GitHub issue by patrykdesign on 2012-08-16T20:56:18Z, https://github.com/mozilla-b2g/gaia/issues/3523] @alivedise I took some screenshots of the font test app Alive wrote and discovered as suspected that B2G does not read point sizes correctly. It appears the OS renders point sizes to about 86-87 ppi not 165ppi (native Otoro) I mapped out what actually is on device vs what it should be. http://cl.ly/image/201Z0d1D0e38 Also why is this important. Most mobile UI is mapped to point sizes. 6pt and 8pt (or equivalent in another measurement) are the most comment sizes of text on many devices.
[GitHub comment by davidflanagan on 2012-08-16T21:10:33Z] According to MDN, 3pt always equals 4px for "low-resolution" devices. Perhaps the otoro is being treated as a low-resolution device. What if we specify font sizes in mozmm units across the board? One point is .353mm, so instead of "10pt" you could use "3.53mozmm"
[GitHub comment by davidflanagan on 2012-08-16T21:12:04Z] Or, if we want the system to interpret pt as real points, then you'd have to file a platform bug on bugzilla. I suspect, however, that making that change might break existing web content.
[GitHub comment by rocallahan on 2012-08-17T02:10:00Z] Some Web content depends on 3pt being always equal to 4px in CSS. Also, the spec says so, and all browsers do this. If you want a particular physical length that's independent of viewing distance (e.g. to size a touch target), use mozmm. But it doesn't sound like that's what you want here. Perhaps you want to change the ratio of device pixels to CSS pixels. 1px should look about the same to the user across devices, i.e. the angle subtended at the eye should be approximately the same (0.0213 degrees) whether you view 1px on a desktop display at arms length or a mobile device at a closer distance. See http://www.w3.org/TR/CSS21/syndata.html#length-units.
[GitHub comment by patrykdesign on 2012-08-17T13:44:42Z] @davidflanagan @rocallahan The key issue here is scale. We should be able to set text size for each form factor and when a new device comes along we shouldn't need to adjust pixels. All our phone UI will use 6, 7, 8 & 10 pt for various elements. I suspect that is the issue, that 3pt = 4px. So can I just use mozmm? I would be happy with that, if it supported across our entire UI. Can you confirm?
[GitHub comment by rocallahan on 2012-08-17T14:23:20Z] You probably shouldn't use mozmm here as I mentioned above. That will give you the same physical length no matter what kind of device and viewing distance you have, which is wrong for reading text. You need to set the default ratio of device pixels to CSS pixels to the right value for each device so that 1px looks the same size across all devices (approximately 0.0213 degrees subtended at the eye).
[GitHub comment by patrykdesign on 2012-08-18T18:28:25Z] @rocallahan The key here is to have a minimum text size spec'd. In this case its 6pt for smallest text size on device. And 8pt for body text. Currently we don't have the tech I initially scoped to have font sizes increase and decrease per device size and ppi, but this needs to happen in v.2+. And font sizes need to be linked to physical size not pixel size as pixel density shifts from device to device unlike on desktop. I believe this is why mozmm was initially invented.
[GitHub comment by davidflanagan on 2012-08-19T06:42:41Z] @patrykdesign: @rocallahan is completely right. I never should have suggested mozmm, and, in fact, I argued against it at length during "flexible UI" discussions a couple of months ago. Generally, I think the only form factors we want to have to design for are the basic device pixel resolutions. Ideally, Gaia will look the same on all 320x480 devices, regardless of their physical screen size. That is, they'll display exactly the same pixels. If the screen size is large, the text will look larger, but the user will hold it farther from their face. And on small screens, the text will look smaller, but the user will be young and have sharp eyes, or will hold it closer to their face. If you tie font sizes to physical screen sizes, and you have n different physical screen sizes, and m different localizations of the text on the phone, then there are n times m combinations and somewhere you're going to end up with text that doesn't fit in the box allocated for it. I honestly think that text should be tied to pixels so that you have pixel-for-pixel fidelity on all devices in the same resolution class. The simplest thing might just be to specify font sizes in pixels. Or use points with the 4/3 conversion factor. Then, of course, you use CSS media queries to alter those pixel-based font sizes for different classes of devices. In the Flexible UI thread some time ago, I argued for using rems. These are a new unit "root em" based on the font size of the root <html> element. You define a single base font size on the root element and that becomes 1rem throughout the document. If you do it that way, then all your media query has to do is set the root font size based on the device resolution and everything else based on rems will adjust automatically.
[GitHub comment by rocallahan on 2012-08-19T22:03:55Z] @patrykdesign: I get the feeling you don't understand what I'm saying. Maybe we should have a phone call or something. @davidflanagan, feel free to set one up if you think it's needed.
[GitHub comment by patrykdesign on 2012-08-20T00:57:43Z] @davidflanagan @rocallahan I believe I understand what you're saying. We need to optimize our UI for usability and form factor. People don't hold the iPhone 25% closer to their face than a Galaxy Nexus just because the screen is 25% smaller on the iPhone. A phone is a phone, people use each form factor a certain way. On tablets for instance the default font size would be 9 or 10 pt depending on the size of the device, not the resolution of the screen, people don't hold the retina display further out the resolution increased not the screen size. So making text less legible because the screen has a higher ppi but still is 320x480 in pixels is not a good practice. Sure its easier without a flexible UI, but considering the potential use of the platform we need font sizes that are optimized for reading not locked to screen size. That is why I was pushing for the flexible UI to work in a certain way, to maximize usability, revolve around font size and making things look legible for each instance. If the smaller text size we accept on Otoro is 6pt, on a 3" 320x480 device the text shouldn't shrink to a barely legible size of 5.1pt. As far as rems go. We'd still need to specify sizes for the base font size per device correct? If I have 3 phones: 360x480 - 188ppi 320x480 - 165 ppi 480x800 - 233 ppi Each base font size would be different on each of the devices, correct? If that is the case, I'd be okay with it, but then the base font size would still be a based off a physical measurement likely 8pt and then converted to pixels. Also as far as bitmaps go (icons, common controls), we're going to have to create about 4 sizes to cover all phones. We don't be able to introduce a new screen size without extensive testing.
[GitHub comment by patrykdesign on 2012-08-20T00:59:50Z] Also if you want to chat in person (which could be easier) what time would work for you as @rocallahan is in new zealand, correct? Would EST mornings work best?
[GitHub comment by davidflanagan on 2012-08-20T16:24:56Z] > We need to optimize our UI for usability and form factor. People > don't hold the iPhone 25% closer to their face than a Galaxy > Nexus just because the screen is 25% smaller on the iPhone. Do we actually have any data on that? As someone in my mid-40s, I'm finding that I need to hold things further away to read, and would apprecate a larger screen with a larger font. > A > phone is a phone, people use each form factor a certain way. On > tablets for instance the default font size would be 9 or 10 pt > depending on the size of the device, not the resolution of the > screen, I don't think we need to consider tablets for v1. They're clearly a different class of device and would have different fonts and different layouts. > people don't hold the retina display further out the > resolution increased not the screen size. The retina display is a special case because on that phone one CSS pixel is two device pixels. As far as HTML and CSS are concerned, an iphone with retina display is 320x480 just like an old iphone. > So making text less > legible because the screen has a higher ppi but still is 320x480 > in pixels is not a good practice. Sure its easier without a > flexible UI, but considering the potential use of the platform we > need font sizes that are optimized for reading not locked to > screen size. > Allowing text size to change based on physical screen size means that the entire layout of all apps has to change as well. If toolbars at the top and bottom of the screen can change height, then it means that the main display area for each app will have a different width to height ratio for different physical screen sizes. > That is why I was pushing for the flexible UI to work in a > certain way, to maximize usability, revolve around font size and > making things look legible for each instance. If the smaller text > size we accept on Otoro is 6pt, on a 3" 320x480 device the text > shouldn't shrink to a barely legible size of 5.1pt. So if we think that FirefoxOS is going to ship on a 3" device in v1, then we should design for that case, right? > As far as rems go. We'd still need to specify sizes for the base > font size per device correct? I'd argue that you could generally get away with just specifying a base font size for basic resolution categories: 320x480 vs 400x800. Except maybe for some extreme outliers where a 320x480 phone has a tiny screen. > If I have 3 phones: > > 360x480 - 188ppi > 320x480 - 165 ppi > 480x800 - 233 ppi > > Each base font size would be different on each of the devices, > correct? If you really meant 360 instead of 320, then I'd say yes, use a different base font size for each of the three resolutions. But if you meant 320, then I'd argue that 165ppi and 188ppi are close enough that you should keep the displays on those two phones the same pixel-by-pixel. Customers will buy the one that is more comfortable to read for them, based on how their eyes work and how they like to hold a phone. > If that is the case, I'd be okay with it, but then the > base font size would still be a based off a physical measurement > likely 8pt and then converted to pixels. > > Also as far as bitmaps go (icons, common controls), we're going > to have to create about 4 sizes to cover all phones. We don't be > able to introduce a new screen size without extensive testing. The long list of devices and differing ppi values on this page scares me: http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density and makes me think that we should have a much smaller list of configurations. We can't require extensive testing for each ppi value. (Remember for text, we'd also have to test each localization at each ppi value, too!) We should be clear here, too, about what is required for v1. I don't believe that any Gaia app authors are seriously supporting 480x800 anymore. Apps may happen to work at that resolution, but no one will have time to make them work well. For v1, I just don't see how Gaia developers and QA have time to deal with font sizes that vary based on ppi. Looking out further, we're obviously going to have to support other resolutions like 480x800. At that point, within each resolution class, we might want to support small screens and large screens differently (or even S, M and L screens, I suppose). (On that wikipedia page above, I look at the HTC Salsa at 170ppi and the HTC ChaCha at 222 and I see two devices that should probably use different fonts. I think the ChaCha is a pretty extreme outlier though and I don't really know if that is something we'll come up against in practice.) When we do get to the place where we can support small, medium and large screen sizes within a given resolution category, we should consider allowing the user to switch font sizes. Most devices will fall into the medium size category, I assume, and users on those phones should be able to switch to larger or smaller fonts, depending their eyesight. I'll end this by quoting my own posts to dev-gaia. These were from the "Flexible UI/Common UI library discussion" thread at the end of May. I can't find a working link in the archive. Here's how I lead off: > For the sake of example, let's consider two HTC phones. The Salsa and the ChaCha both have 320x480 screens. But the Salsa is a pixel density of 170dpi and the ChaCha has a pixel density of 222. (According to http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density) > This means that the Salsa's screen is 47.8mm wide and the ChaCha's screen is a significantly smaller 36.6mm wide. Any two devices will have different densities; this pair has a substantial difference, which is what makes it useful for this example. > So, if we want our B2G layouts to work on both of these devices, we have (as I understand it) two choices: > A) We make all the UI elements exactly the same size (in mozmm) so they appear the same on the device screen when measured with a ruler. That would mean that the space between the elements would vary and we'd end up with a roomy layout on the Salsa and a possibly cramped layout on the ChaCha. But if we decided that a button should be 1cm high, then it would be *exactly* 1cm high on both devices. > B) We make the displays on these two devices exactly the same pixel-for-pixel. If you put a Salsa and a ChaCha side by side on a table, everything on the Salsa would look bigger than the ChaCha, but the proportions of the layout would be the same on both: you wouldn't have one looking roomy and one looking cramped. In a user's hand, this difference in size wouldn't be so noticeable: ChaCha users probably tend to hold the phone closer to their eyes than Salsa users do. Importantly, touch area on the ChaCha will be physically smaller than the touch areas on a Salsa. Suppose we decide that our minimum touchable area is 10mm x 10mm and we assume a nominal density of 170dpi for this category of 320x480 devices. Then on the Salsa, a minimum touch area will be exactly 10mm and on the ChaCha it will be a tight 7.7mm instead. If you've got big hands and stubby fingers and you buy a ChaCha, you may have trouble operating it accurately. But this seems like a user demographic issue: maybe the ChaCha is marketed at teenage girls with good eyesight and small fingers, for example, and we just have to agree that one size does not fit all. > To me, it seems obvious that choice B is what we want. I think Pavel agrees with me, but I'd like to make sure that there is agreement from the UX and visual design teams as well. And in a followup I wrote: > But if you keep the size of a UI element constant, then the size of the space around the element has to change. And I'm guessing that in practice, for devices with approximately the same pixel density, it will look better if we keep the proportions the same than if we keep the physical sizes the same. > My thinking on this is influenced by the first two tables on this page: https://wiki.mozilla.org/Gaia/Design/FlexibleUI: Basically, most 320x480 devices are around 160dpi. And most 480x800 devices are about 240dpi. > So I think the best approach is to design for 320x480@160 and 480x800@240, and aim to display exactly the same pixels on any device that falls into one of those categories. Given the large variability in the distance between the device and the user's eyes, going for mm-equivalence seems wrong to me, especially since that would make the relative proportions of the layouts different on every device. > In my example, I purposely chose two devices (the Salsa and the ChaCha) that had substantially different pixel densities. At 222dpi, the ChaCha is actually closer to the nominal resolution of a 480x800 device. So perhaps it just wouldn't look right if we tried pixel-for-pixel equivalence with the Salsa. In that case, I'd say we put the ChaCha into a third category of devices, the 320x480@220 category, and we'd have to update our stylesheets to make sure things looked good for that category. If we needed to support a 320x480 device with a 200dpi or 240dpi display screen, we'd probably use this same category. And finally: > A button will be approximately the same physical size on a 320x480 device as it is on a 480x800 device. There's no controversy about that. > But if a button is 2cm by 1cm on on a Nexus S, should it be 2cm by 1cm on a Galaxy S2?. If you answer yes, then: > 1) the proportions between background and UI element will be different > 2) we'll have to be more careful to avoid fractional font sizes and positioning things on sub-pixels > 3) no one will notice anyway :-) > My claim is that if we try to make everything the same physical size, then paradoxically, we'll end up with Gaia looking different on every device (because the proportions will change) rather than looking the same on all devices in the same basic categories.
[GitHub comment by patrykdesign on 2012-08-21T20:33:00Z] @davidflanagan In an ideal world we'd do what Apple has done. Pick an optimal platform (spec) and lock it down to 1 screen size for developper compatibility and maximum UX. Unfortunately that is not the case, we are under the mercy of the market which our partners find themselves in, to deliver a device to a certain economic segment and therefore that limits our input on the hardware spec. So to be successful in our situation we need to keep our options open, so expect there to be various hardware specs and in turn screen sizes. Proportions matter then it comes to visual design. But they don't matter to the user as much, especially over usability. I don't want to inflate buttons and text sizes arbitrarily. I want to make sure they conform to MINIMUM usability standards. We don't have the luxury to market our device to 17 year old teenage girls with slim fingers and great eye sight. The UI has to be fairly general purpose. In the markets we are aiming for it will be aimed at adults of all shapes and sizes. Therefore minimum touch heights and font sizes are a must. From the user research in our target market, people buy phones based on a few features (like camera resolution, tv or radio), phone colour (red is very popular) and price. Our ideal situation is that they would then recommend the phone to other people cause its actually NOT a pain to use. Rather than suffer cause they couldn't afford a premium handset. Small text and non responsive buttons are going to be painful. Nothing can be smaller than 6pt, to be readable for the masses. Nothing can be smaller to touch than 7x7mm or a row item of 5.5mm. These are industry known figures. Yes our base is 320x480 on a 3.5". If for v.1 we'd have to inflate the font and button size proportionately to fit on a larger screen, I am okay with that. Just nothing should shrink. I believe in my initial spec for flexible UI I suggested to create the UI to fit several buckets. 320xXXX @160 ppi 480xXXX @ 240 ppi 720xXXX @ 300 ppi Those resolutions seem to cover most screens. I just want to make sure we don't scale (up or down) a 320x480 design to fit 720x1280, we should approach each resolution as a separate entity, with custom layouts.
[GitHub comment by davidflanagan on 2012-08-22T05:40:25Z] > I believe in my initial spec for flexible UI I suggested to create the UI to fit several buckets. > 320xXXX @160 ppi > 480xXXX @ 240 ppi > 720xXXX @ 300 ppi > Those resolutions seem to cover most screens. > I just want to make sure we don't scale (up or down) a 320x480 design to fit 720x1280, we should approach each resolution as a separate entity, with custom layouts. That sounds great to me. I completely agree that we need to explicitly handle each distinct resolution. I was worried that you were saying that you would also like to change the font size based on ppi within resolutions. That a 320x480@160 device might use different fonts than a 320x480@180 device. So, doing some calculations here... If you calculated your minimum sizes based on a 200ppi device, then 6pt would be 16.7px. And when those 16.7px were displayed on a 160ppi device, they'd be 7.5pt high. And 7mm on a 200ppi device would be 55px. And those 55px when viewed at 160ppi would be 8.75mmx. Those seem like reasonable variations to me. Do figures like those work for your designs? Can we pick pixel values like those as minimums and use them for any screen resolution between 160ppi and 200ppi? I think I've been using 50px high buttons in the gallery app, so they'd be a little small on a 200ppi device, I suppose. @patrykdesign @rocallahan Do we still need our vidyo meeting tomorrow, or have we sorted things out here?
[GitHub comment by rocallahan on 2012-08-22T06:08:51Z] It still seems to me that I failed to communicate what I wanted to communicate. "Nothing can be smaller than 6pt, to be readable for the masses." --- yes, but at what viewing distance? This statement is meaningless without a specified viewing distance. CSS is set up so that the size of a CSS pixel depends on expected viewing distance, and objects that are the same size in CSS pixels will look about the same size no matter what kind of device they're rendered on. CSS pixels *are not* the same as device pixels and they *should be* independent of device pixel density. So, if you assume that all phones are held at about half of arm's length, then following the CSS spec we should set up the default scale for applications (and for Web sites that we're not zooming) so that 1 CSS px is about 1/192 of an inch --- regardless of the device pixel density. Then 1 CSS pt will be about 1/144 of an inch, on all phones. Then you can use px and pt units for your UI and get visually consistent results across devices; things that are the same size in CSS px will look about the same size on each phone. If that is all clear and uncontroversial then we don't need to have a phone call, otherwise I think we should.
[GitHub comment by davidflanagan on 2012-08-22T07:15:39Z] I think that @patrykdesign is citing received wisdom from the mobile phone industry with his 6pt minimum. And that presumably factors in what the cell phone industry has learned about how people interact with the devices. So I'm willing to go with that, though it would be clearer if we said 1/12th of an inch instead of 6 pt, since on computers point sizes actually vary a lot @rocallahan what does it mean to "set up the default scale"? There's a preference we can set to do that, right? Call me old fashioned, but the idea of css pixels not matching device pixels (or at least one being an integer multiple of the other) freaks me out. Have we done that before? Do we do it for Fennec, for example? Do we run into rendering issues if we get into fractional device pixels? I don't think we should open a new can of worms for v1. If we do as you suggest, then Gaia apps on a 320x480@160 device will look different (not just different size) than they would on a 320x480@200 device, right? And we'd have to QA each physical screen size to make sure all the text fit into all the boxes. While that kind of scaling makes sense for web content, I don't like the idea of applying it to our apps. I think they should render pixel-for-pixel the same on all 320x480 devices with ppi values between 160 and 200
[GitHub comment by patrykdesign on 2012-08-22T20:17:42Z] @rocallahan @davidflanagan point sizes is one measurement. If we go with something else, that is fine as well. Just let me know what measurements you are using as currently all our designs are based on point sizes. The requirements here should be the following: 1. Whatever we spec out on our base device (Otoro), those are the comfortable minimums and we should try very diligently not to go below those. 2. These specs should be able to scale up to various platforms. Android uses (density independent pixels) we'll likely need to do something similar.
[GitHub comment by patrykdesign on 2012-08-22T20:19:42Z] @davidflanagan and as far as doing what I am proposing. BlackBerrys all ran on point sizes. Each release we shipped 5-10 different devices all different screensizes, and that was the only way of insuring that font sizes stayed consistent. The only burden was testing everything. But with a flexible UI things didn't break.
[GitHub comment by rocallahan on 2012-08-22T20:56:08Z] The preference is "layout.css.devPixelsPerPx". We change the ratio of CSS pixels to device pixels any time you zoom in the desktop browser so it's pretty well tested on the Gecko side, although there may be some B2G specific bugs I suppose. If you want to cluster devices into a small number of equivalence classes for QA purposes, you could still do that by restricting the set of layout.css.devPixelsPerPx values you allow yourselves to use, and using the closest value in that set for each device. If you do that clustering, then you can still set a default font size particular to each device and use "root em" units to access that font size from anywhere in your stylesheets. The more variation you allow, the more QA you have to do. The tradeoffs are entirely under your control. > 320xXXX @160 ppi > 480xXXX @ 240 ppi > 720xXXX @ 300 ppi If we took those as our canonical configurations then we could say that the allowed values of layout.css.devPixelsPerPx are 3.3333, 5 and 6 respectively. The respective screen sizes would be 96px, 96px and 120px respectively. So for most apps you should be able to create a single layout that works well across those devices. (To make UIs look the best, you will still need to do some additional work: create resolution-specific images and select the right image using media queries. No way around that.) (Note that you can use fractional CSS pixels to create visual features with less than 1 CSS px size, if you need to.) So we have the tools to do resolution-independent layout with CSS. It sounded like you're considering ignoring those tools and hardcoding 1 CSS px to 1 device pixel, even on a 300 ppi device. That is not the right thing to do IMHO; apart from forcing app developers to create different layouts for each device (and be badly broken on devices that they haven't tested on), it's not how the Web works, so it undermines our "the Web is the platform" approach. You might choose to ignore those tools for V1 and try to adopt them in V2, but you'd be setting yourself up for a ton of extra work and confusion IMHO.
[GitHub comment by rocallahan on 2012-08-22T21:05:11Z] Oops, I got those numbers wrong. The allowed values of layout.css.devPixelsPerPx would be 0.83333 (better call it 1), 1.25, and 1.5625 (call it 1.5). Then your screen sizes would be 320px, 384px, and 480px.
[GitHub comment by rocallahan on 2012-08-22T22:47:54Z] > Android uses (density independent pixels) we'll likely need to do something similar. CSS px is exactly that.
[GitHub comment by patrykdesign on 2012-08-23T15:21:45Z] @rocallahan I would also be fine if we created thresholds. Ie. if the screen gets smaller than 160ppi than we us the layout spec'd for 120-159ppi. And if the screen size drops below that threshold than we'd pick a different layout, the only thing I don't like about this is that on some devices the fonts will be bigger than we ideally would want.
[GitHub comment by davidflanagan on 2012-08-23T16:20:17Z] @patrykdesign do you make any distinction between fonts used in the UI and fonts used for longer chunks of text? The browser and email apps are ones that have to display legible paragraphs of text. I assume the needs for legibility there is greater than in buttons, etc. And I'd assume that apps like those will actually give the user the option to user larger or smaller fonts... It sounds as if we may have arrived at a resolution to this, but I feel bad that the entire discussion was in this bug. Should we open this up (or at least publish our conclusions) on dev-gaia?
[GitHub comment by autonome on 2012-09-05T15:48:03Z] Blocking-, don't break the Web. Would be nice to have clever solution for V2, but we'll live with this for V1.
For v.2
Priority: -- → P2
Whiteboard: [label:needsVISUALinput] → [label:needsVISUALinput] V2
Whiteboard: [label:needsVISUALinput] V2 → visual design, v2
Priority: P2 → P5
I am curious as to why there is this discussion regarding points for dimension. Is this related to a lower level Gecko thing? I have never seen or heard of a use case for points in CSS unless it is for maybe a print style sheet. Should we not just have a base font size set in pixels or em and then use rem from there on? And as @davidflanagan suggested using media queries to adjust the base font size.
Hi Patryk, what's happening with this bug? Will this be looked at closer to V2?
Flags: needinfo?(padamczyk)
This will need to be addressed for flexible UI. We need for physical dimension is needed as its impracticable to hand code font sizes for each device screen size we ship.
Flags: needinfo?(padamczyk)
Whiteboard: visual design, v2 → visual design, flexible ui, yedo
blocking-b2g: --- → leo?
blocking-b2g: leo? → ---
Mass edit to set tracking-b2g18+ for these UX bugs that were called out for v1.1
tracking-b2g18: --- → +
Whiteboard: visual design, flexible ui, yedo → visual design, flexible ui
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.