Closed Bug 829596 Opened 12 years ago Closed 12 years ago

Remove "Tablet" from UA string of Firefox on Android tablets

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla21

People

(Reporter: gerv, Assigned: dao)

References

Details

(Keywords: dev-doc-needed)

Attachments

(2 files)

patch
954 bytes, patch
bzbarsky
: review+
Details | Diff | Splinter Review
backout patch
769 bytes, patch
mfinkle
: review+
Details | Diff | Splinter Review
After discussion in mozilla.dev.platform, the conclusion is that we should remove the word "Tablet" from the tablet UA, thereby making it just like the desktop UA (except with a different OS). Here is the posted message: <blockquote> Hi everyone, After taking all input into account, I have decided that we should drop the "Tablet" token from Fennec's UA on tablets. This is what Android browser and Chrome do, and corresponds to option D) of my original options. So for non-"Mobile" devices, it would be: Mozilla/5.0 (Android; rv:12.0) Gecko/12.0 Firefox/12.0 We should be aware that we _may_ in the future need to add "Touch" on Windows 8 Metro only, if developers start detecting it in large numbers and consequently sites start breaking. We should write up on MDN and publicise a document of best practices in detecting and using touch events cross-browser, to try and make that less likely. It's relevant to note that, according to recent ADI data, Tablet users make up about 25% of Fennec installs, for a total of about 388,000 ADIs, so perhaps a million users. (Thanks to Anurag Phadke on the Metrics team for getting the data for me here.) To elaborate on some points people may ask about: - We would therefore use "Mobile" on devices where we thought a mobile experience should be the default, and the desktop UA where we think a desktop experience should be the default. At the moment, opinion seems to be that phones are "Mobile" and tablets from 7" up are not, but we have the flexibility to change that view later. - Given the short time this token has been in use, and the small number of Tablet Fennec users (relative to e.g. desktop), we don't expect significant compatibility problems. The speed we deploy this change is a trade-off between "minimising the number of browsers with the old UA" and "making sure we can detect any compatibility problems". So therefore the exact timing and train schedule of deployment of the change would be a matter for the release-drivers. - For the above reasons (short time, relatively small number of users), I am not too concerned that large numbers of web developers are going to have been detecting our "Tablet" string, or that this will lead to frustration at our "ever-changing" UA. - This decision is going to be widely publicised so that any necessary sirens can be set off, to make sure everyone who might be affected is aware. Lastly, I'd like to apologise for putting "Tablet" in in the first place. That was my call, and it was a mistake. </blockquote> Related: bug 773355. Gerv
dao: is this something you can whip up a patch for? Including ESR17? Gerv
I don't think this qualifies for the ESR branch.
Assignee: nobody → dao
Johnath asked for a clear statement of benefit. I guess that would be: Keeping the UA as similar as possible across platforms removes the possibility of some Firefoxes being excluded by foot-shooting developers. The change under consideration removes a relatively-recently-added tag on the Tablet Firefox only, reverting it to be the same as Desktop Firefox. This makes it more likely that neither one nor the other will be excluded from sites by bad sniffing. Gerv
Attached patch patch — — Splinter Review
Attachment #701193 - Flags: review?(bzbarsky)
Comment on attachment 701193 [details] [diff] [review] patch r=me on the code. I assume that the actual behavior change was agreed on...
Attachment #701193 - Flags: review?(bzbarsky) → review+
I'm sorry that I'm late with this comment but I just tested this new UA in WURFL, a popular UA detection framework among sites such as Facebook. WURFL does not detect the proposed UA as a tablet. Given our struggles in getting UA detection frameworks to correctly detect our UA, I wonder if we should reconsider this change. Below is the WURFL result for the proposed UA: http://tools.scientiamobile.com/?user-agent-string=Mozilla%2F5.0+%28Android%3B+rv%3A12.0%29+Gecko%2F12.0+Firefox%2F12.0 Below is the WURFL result for the existing UA that includes the "tablet" token: http://tools.scientiamobile.com/?user-agent-string=Mozilla%2F5.0+%28Android%3B+Tablet%3B+rv%3A14.0%29+Gecko%2F14.0+Firefox%2F14.0
Similarly, both Categorizr [1] and 51degrees.mobi [2] detect the proposed UA as mobile and the existing UA as tablet. In talking about expected breakage, these results suggest to me that there is a strong argument to keep the existing Fennec tablet UA. [1] http://brettjankord.com/categorizr/ua-check.php [2] http://51degrees.mobi/Products/DeviceData/UserAgentTester.aspx
Well, the aim of making the UA the same as the desktop one (in the way we are changing it) is so that it gets detected as a desktop as opposed to a mobile. So WURFL not detecting it as a tablet is not necessarily a bad thing. (I notice the results for the UA that it _does_ detect as a tablet give a resolution of 480x800. That's going to be wrong for at least the majority of tablets on which it runs. If people are relying on data from WURFL with the current UA, stuff is going to be wrong too. WURFL is a broken model.) Detecting the new UA as a mobile device even though it doesn't contain the string "Mobile" is a bit sucky. 51 Degrees actually detects the new UA as "Generic Android", which is probably about right, I'd say. Categorizr detecting it as mobile is wrong. But that seems to have a "report as incorrect" button. What if we press it? Gerv
https://hg.mozilla.org/mozilla-central/rev/196ed5ab68a1
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Lawrence: the fix has only gone in to m-c, so is quite reversible technically. We should carry on this discussion; you know I value your opinion. I think it's clear that if a system is doing mobile/desktop, we want "desktop". (Otherwise, we'd put "Mobile" in the string.) If it's doing mobile/tablet/desktop, we do probably want "tablet", and as a fallback "desktop" - definitely not "mobile". But how would "tablet" be detected? We don't provide hardware identifiers - is that what these systems use for detecting tablets in other cases? I know the Android stock browser and Chrome don't say "Tablet". Do we want them to assume in our case that if it's Android and it's _not_ Mobile, it's a tablet? Or do we just want to reject the category, and say "actually, we want your desktop site; if you have touch-based stuff, do touch detection"? Gerv
I submitted a bug report to Categorizr: http://www.brettjankord.com/2012/01/16/known-issues-with-categorizr/#false-postives and emailed 51Degrees via their web form. Gerv
Gerv, I disagree. We want a touch-based interface on tablets, not a desktop/mouse-based interface. But mostly I object to changing our UA once again.
Depends on: 837215
Was it a good idea to remove this without testing? E.x, Facebook now serves an ultra-basic WAP version to tablet users of Firefox on Android on mozilla-21; a regression from Facebook users using release and beta getting a desktop version.
Currently this is only in Nightly, which is our build _for_ testing. I emailed Tony Chung to ask him to look at putting together a test plan to measure the impact. We can pull this off a train at any time if necessary. I hear Facebook uses WURFL; I believe Lawrence is working with both WURFL and Facebook to get their use of it straightened out. Lawrence: is this on your list of issues? Gerv
To Aaron's point, I want to ensure that this doesn't get uplifted to Aurora until full impacts of most oft-used websites are known. I am also hesitant of changing the UA again, although more concerned about user impacts (especially given that 25% of our users are tablet ones). I would want reassurance that we're providing more benefit than angst with this change, so will want to tread carefully with this change and base it on a fair bit of QA analysis. In general, I like the idea of using desktop site layouts for the tablets due to the bigger screen size, but it needs to behave like a touch-based mobile. One more consideration: on the list of to-dos for me, I was going to work with UX to determine a better 'phablet' experience. By changing the UA to remove any reference to tablet, could this have impact on this initiative? Especially as tablets gain more ground with the possibility of developers creating 'tablet' sites? I'd like some time to see if we can get that question answered and identify any potential trend in that area.
Some clarifications: * Including "Tablet" in the UA for tablets is by no means a standard * With "Tablet" removed, Fennec is still not using a true desktop UA. We still have "Android" in the UA. I would like to stop churn, which breaks sites like Facebook. I'd like to know if WURFL was depending on the "Tablet" token or not.
(In reply to Mark Finkle (:mfinkle) from comment #17) > I would like to stop churn, which breaks sites like Facebook. I'd like to > know if WURFL was depending on the "Tablet" token or not. I can answer my own question: Without "Tablet" http://tools.scientiamobile.com/?user-agent-string=Mozilla%2F5.0+%28Android%3B+rv%3A12.0%29+Gecko%2F12.0+Firefox%2F12.0 With "Tablet" http://tools.scientiamobile.com/?user-agent-string=Mozilla%2F5.0+%28Android%3B+Tablet%3B+rv%3A12.0%29+Gecko%2F12.0+Firefox%2F12.0
Oh, the answer is "Yes, WURFL is depending on the 'Tablet' token"
(In reply to Gervase Markham [:gerv] from comment #15) > I hear Facebook uses WURFL; I believe Lawrence is working with both WURFL > and Facebook to get their use of it straightened out. Lawrence: is this on > your list of issues? Yes. I have a list of updates to send to WURFL. I can include an update to the Fennec tablet UA. However, I don't want to go back later with hat in hand asking them to revert the change. I would prefer that we be as confident as possible that this change is going to stick. Once WURFL is updated I will communicate the change to Facebook so that they can pick up a newer version of the WURFL db.
[tchung: is there any news on a testing plan for this change?] We discussed this topic in quite great detail, and the conclusion was that we should change this. There is no perfect answer which makes everything work as we'd like in all cases. I'm certainly open to arguments about timing, but I'm not sure that (in absence of significant new information) revisiting the decision would be a good use of time. If anyone disagrees strongly, speak up now because, as Lawrence said, having to get WURFL to change _again_ in a couple of months would be a real pain. (Although I continue to maintain that their entire model is broken.) If people want to make touch websites, they should detect touch support. That's the best thing for the web as a whole, because then their websites will do the right thing on all devices, rather than on some devices. I believe there's a hacks.mozilla.org post in the works on the best way to do this. The uplift to Aurora if we take no action is on the 18th of Feb. Gerv
I wonder if we should make the WURFL change regardless of what we do with the "Tablet" token in the UA. The mobile Chrome docs for UA have a pattern we could suggest for determining Phone vs Tablet: https://developers.google.com/chrome/mobile/docs/user-agent <blockquote> Like all other browsers, Chrome for Android sends this information in the User-Agent HTTP header every time it makes a request to any site. It’s also available in the client through JavaScript using the navigator.userAgent call. If you are parsing user agent strings using regular expressions, the following can be used to check against Chrome for Android phones and Android tablets: Phone pattern: 'Android' + 'Chrome/[.0-9]* Mobile' Tablet pattern: 'Android' + 'Chrome/[.0-9]* (?!Mobile)' </blockquote> A similar pattern could be used for Firefox.
Attached patch backout patch — — Splinter Review
I object strongly. * This breaks the content we get on tablets for top sites. * Every time we change our UA we burn credibility with UA detection frameworks. * WURFL is the leading UA detection framework, but it is not the only one. Even if we get them to change their detection it does not solve the problem. * I fail to see the advantage of this change. * It throws out any progress we've made over the last year in terms of people recognizing our UA correctly. * The "tablet" token is already a generalization. Most mobile browsers put the device make and model i the UA string. * Android should not automatically imply touch (as others have suggested in this bug).
Attachment #710341 - Flags: review?(mark.finkle)
Reopening for backout per comment 23.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I do object to a backout right now, on the basis that a) this change was the result of a community consultation and discussion process which should not be lightly cast aside, and b) it makes it harder for tchung to do the testing we've requested to look at the impact of the change. This is what mozilla-central is _for_. If Brad or someone else has further data we need to take into account, then let's do that - but as the next Aurora uplift is on 28th Feb (AIUI) then it's not urgent to have this done in the next 24 hours. Gerv
Aurora uplift is on the 18th, not 28th. There are less obtrusive ways to test UA changes. I think we need to explore those _before_ making a code change, not after. Also, we should be working with WURFL, other UA vendors and web sites before making a change that can cause problems - and yes, we could have known this was going to cause problems before it landed. I feel we are being a bit cavalier about the UA changes in a shipping product.
I apologise if I missed any dev.planning thread that was used to discuss this, but I feel rushed in making this change and uplifting to Aurora without understanding all the implications. I understand the desire to do the right thing here, but I also hear that doing the right thing has not been (and is not) a clear cut case. I worry that we will not have enough information to determine how many sites will break as a result -> I think this will take some major effort to ensure we have mapped the 'top sites' to see where they get their info from and ensure nothing breaks with whatever transition is agreed. I worry that with the increase in tablet volumes and, as a consequence, developers creating tablet-friendly websites (hybrid between desktop & mobile), we won't be detected as tablet. I also worry about supporting a UA string that fewer and fewer databases recognize as tablet -> which leads to, presumably, the reason why you want to make the change. BUT I'm not yet getting the sense that we know enough about which sites use which library and the impact of changing the UA. One thought to be explored is whether we can try prepare ourselves for a change before making the change? i.e. begin the process of updating databases, ensuring top sites won't break, evangelizing the change way way way in advance before switching over? In the mean time, I'd like to see that dropping 'tablet' and relying on 'android' (without 'mobile') really does feed us the tablet-friendly site today on the majority of top sites and that the trend for major developers is to continue down that path (instead of looking for other hooks to give the right site version). Feb 28 seems really close to me, especially with MWC ramp-up. I'm not sure we would have the QA info in hand or a clear sense of whether developer trends will be focusing solely on an 'android' hook in the string? I profess to not being an expert in this area. However, I do know that I want to ensure that the UX on any Fennec product is well protected and always moves us forward. I am being cautious because I want to be satisfied that we won't regress - and if we can put mitigating steps in place for a smoother transition that safeguards the tablet experience, I'd feel much more comfortable with such a change. But as this impacts 25% of our current users, I wish to be more conservative in this matter and ensure we have done all the QA and due diligence necessary to limit site breakages. I think Vishy hopes to bring folks into a meeting for a discussion on the topic so we can all feel comfortable with the plan forward.
Mark: thanks for the correction on the date. I don't think it's an appropriate description to describe mozilla-central as "a shipping product". How would you prefer that we test UA changes on Firefox for Android on tablets? Karen: you can read the discussion we had in these two threads in mozilla.dev.platform from December: https://groups.google.com/forum/#!topic/mozilla.dev.platform/tT-oz7yJ6VM/discussion https://groups.google.com/forum/#!topic/mozilla.dev.platform/qyiGrwzZjvE/discussion The first is the discussion thread, and the second is the decision with rationale, and the resulting thread from that. Many of the issues you touch on were raised at one of those points. Gerv
(In reply to Gervase Markham [:gerv] from comment #28) > Mark: thanks for the correction on the date. I don't think it's an > appropriate description to describe mozilla-central as "a shipping product". > How would you prefer that we test UA changes on Firefox for Android on > tablets? Last time we changed the UA, we used Phony and an automated script to create screenshots of the top 100 mobile sites. We did a side-by-sdie comparison, with and without the UA change. Given that UA changes typically involve evangelism and evangelism is a long process, whatever testing we can do before landing a patch would be helpful. As soon as the change lands in Nightly, we run the risk of confusing webdevs and large web properties into wondering "is this the new UA or a test UA?".
(In reply to Gervase Markham [:gerv] from comment #3) > Johnath asked for a clear statement of benefit. I guess that would be: > > Keeping the UA as similar as possible across platforms removes the > possibility of some Firefoxes being excluded by foot-shooting > developers. The change under consideration removes a > relatively-recently-added tag on the Tablet Firefox only, reverting it > to be the same as Desktop Firefox. This makes it more likely that > neither one nor the other will be excluded from sites by bad sniffing. > > Gerv How much greater is this benefit compared to allowing for finer detection of devices / more optimized content retrieval? FWIW, the increasing penetration of mobile and expansion of form factors only increases the need for finer detection. It might be that there are better ways of doing that than the UA string, but if this is what is being used, we need to go with it until we have a programme / value prop to doing it the other way. Especially on mobile, where we don't have lots of market leverage (yet).
Lawrence, Brad, Mark and I have decided to back this out pending further compatibility testing, which Lawrence is going to negotiate with the QA team about. We hope to be able to evaluate the situation again prior to 18th Feb. Gerv
(In reply to Irina Sandu from comment #30) > How much greater is this benefit compared to allowing for finer detection of > devices / more optimized content retrieval? The finer the device detection, the bigger the privacy problem. So there is a trade-off here. And there's the issue that the more we collaborate with and take actions which promote the use of device detection frameworks, the harder it is for new devices to enter the market, which is anti-user-choice. There is some info which device databases provide which site operators do need; we need to find a way to provide it without compromising privacy or excluding new market entrants. But that's not a subject for this bug. Gerv
Attachment #710341 - Attachment is patch: true
Attachment #710341 - Flags: review?(mark.finkle) → review+
I have no problem running a screenshot-compare against a top-100 for comparison w/both UA's. If that's of value, I'll post here when complete.
Depends on: 839065
The UA now has a 'Linux armv7l' token in it; see dependancy bug.
From Aaron's comparison run, I see notable differences in: Facebook Yahoo Yandex mail.ru BBC Pornhub YouPorn Interestingly enough, one of the implicit assertions stated in the description is that this change should help tablets receive desktop content. "We would therefore use "Mobile" on devices where we thought a mobile experience should be the default, and the desktop UA where we think a desktop experience should be the default." In fact, the sites above send a phone optimized mobile site when the "tablet" token is absent from the UA and send a desktop/tablet site when the "tablet" token is included in the UA.
(In reply to Lawrence Mandel [:lmandel] from comment #37) > From Aaron's comparison run, I see notable differences in: > Facebook > Yahoo > Yandex > mail.ru > BBC > Pornhub > YouPorn > > Interestingly enough, one of the implicit assertions stated in the > description is that this change should help tablets receive desktop content. > > "We would therefore use "Mobile" on devices where we thought a mobile > experience should be the default, and the desktop UA where we think a > desktop experience should be the default." > > In fact, the sites above send a phone optimized mobile site when the > "tablet" token is absent from the UA and send a desktop/tablet site when the > "tablet" token is included in the UA. This isn't surprising, since we gave them the Tablet token exactly for that purpose. They can however do the exact same thing solely based on the presence/absence of the Mobile token. If this mostly affects a few popular sites (apart from WURFL), we could also add overrides for them.
(In reply to Dão Gottwald [:dao] from comment #38) > This isn't surprising, since we gave them the Tablet token exactly for that > purpose. They can however do the exact same thing solely based on the > presence/absence of the Mobile token. I think the interesting part is that the expectation was that without the "Mobile" or "Tablet" token the expectation was that desktop content would be served. This example shows that the key to sites serving mobile content is not the "Mobile" token but rather the "Android" token. > If this mostly affects a few popular sites (apart from WURFL), we could also > add overrides for them. We can but each override is an acknowledgement of broken content that we need to go out and evangelize. Evangelism is in many cases a slow slog. It will benefit us all to get out of the cycle of fixing the same few top sites and move on to other fixing other sites.
> This example shows that the key to sites serving mobile content is > not the "Mobile" token but rather the "Android" token. Right, if they hadn't sniffed for Android, there would have been little reason for adding Tablet in the first place. We should still tell them to sniff for Mobile instead, since that's the way not to lock out other OSes. > > If this mostly affects a few popular sites (apart from WURFL), we could also > > add overrides for them. > > We can but each override is an acknowledgement of broken content that we > need to go out and evangelize. Evangelism is in many cases a slow slog. Right, but with overrides in place we can wait and get out of panic mode.
I think getting into situation where Android && !Mobile == Tablet. Consider Google TVs currently in the market and any other manor of other products coming down the track
I think getting into situation where [Android && !Mobile == Tablet] is not where we want to end up. Consider Google TVs currently in the market and any other manor of other products coming down the track.
(In reply to Brad Lassey [:blassey] from comment #42) > I think getting into situation where [Android && !Mobile == Tablet] is not > where we want to end up. That's not what we should tell people either. The absence of Mobile should just result in what you'd get with desktop Firefox. Minor adjustments for touch input can happen on the client side if wanted. > Consider Google TVs currently in the market and any > other manor of other products coming down the track. So right now some sites would treat such devices as smartphones because of the Android token. This is broken. They should get the mobile version only if a device sends the Mobile token. Otherwise they should get the desktop version. If there's a new type of device so different that neither mobile nor desktop make sense, I suppose a new token would have to be introduced.
(In reply to Dão Gottwald [:dao] from comment #43) > That's not what we should tell people either. The absence of Mobile should > just result in what you'd get with desktop Firefox. Minor adjustments for > touch input can happen on the client side if wanted. Whether or not this is how things "should" be, it doesn't reflect how many authors are doing web development today. They very often develop sites optimized for touch tablets that are in many cases quite different from desktop, and on their "desktop" sites they rely on features like :hover that work badly on tablets. If Firefox doesn't let them distinguish these cases easily, then Firefox will be a worse user experience than competing tablet browsers. We ourselves don't believe that tablet and desktop can use the same basic design with "minor adjustments for touch input". Firefox for Android tablets is almost nothing like Firefox on desktop, and neither is the upcoming Firefox for Windows 8 Metro. If we as app developers feel the need to use radically different designs on tablets than on desktop platforms, why are we hoping to discourage web app developers from doing the same? (In reply to Dão Gottwald [:dao] from comment #38) > If this mostly affects a few popular sites (apart from WURFL), we could also > add overrides for them. I don't see any evidence that this affects only "a few popular sites." I would wager instead that these sites are just the first ones we will detect with the limited time and amount of testing we can do ourselves. We have only 2000 fennec ADI on the nightly channel. When we go to release where we have a thousand times more users, I expect they will find many times more affected sites.
Matt, you're bringing up points as if they had never been discussed before. :hover styling can be adjusted easily on the client side. However, if we think adjustments for touch input need to be more severe, then we should consider bug 773355, as "Touch" communicates that more directly, could be added for new touch devices that aren't tablets, and would get us some cross-browser compatibility.
(In reply to Brad Lassey [:blassey] from comment #42) > I think getting into situation where [Android && !Mobile == Tablet] is not > where we want to end up. Consider Google TVs currently in the market and any > other manor of other products coming down the track. Just an FYI. It seems Chrome does have a GoogleTV specific UA [1]: Sony Bravia Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Large Screen Safari/533.4 GoogleTV/ 162671 Logitech Revue Mozilla/5.0 (X11; U: Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Large Screen Safari/533.4 GoogleTV/b39389 Notice: * No "Android" * Adds "Large Screen" It's a desktop UA with "Large Screen" [1] https://groups.google.com/forum/?fromgroups=#!topic/android-developers/YKfdexMXfMI
Here's where my thinking is at the moment: - We have missed the boat on making this change without affecting the web. So the question now is: do we make it anyway, and take the evangelism hit, or do we accept that our UA now is what it is, and work with it? - The evangelism team is understaffed and very busy. Is it worth having them work on this at the expense of dealing with sites which are already sending bad content with our current UAs? - Lawrence mentioned that our stock is not high at WURFL. Even if we are not fans of their model, lots of sites use them (Facebook!) and open warfare is to be avoided. - If we have decided not to collaborate entirely with the WURFL-style "your device has to be in my database and then I know everything about it, otherwise who knows" model, then it's still true that there are things web developers legitimately want to know about the client, and we need ways to tell them. - Databases like WURFL have an "is_tablet" marker. While I think there are going to be problems down the road when people argue about what that means on hybrid devices, the fact remains that it's there. How do we expect people to set it? As Brad notes, if we aren't careful we'll end up with "Android && !Mobile", which would not be a good place to be in. - We should investigate other mechanisms for transmitting information such as screen size (in either, inches, pixels, DPI, or 2 of the 3). So I'm leaning towards saying: OK, let's keep the marker, and worry about what is and isn't a tablet (and so what does or does not get the marker) when we hit those problems later. Gerv
WONTFIX per comment 47. Gerv
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WONTFIX
(In reply to Gervase Markham [:gerv] from comment #12) > I submitted a bug report to Categorizr: > http://www.brettjankord.com/2012/01/16/known-issues-with-categorizr/#false- > postives > and emailed 51Degrees via their web form. > > Gerv Gerv - Given that this change has been backed out, can you please follow up with Categorizr and 51Degrees to ensure they don't pick up this change?
(In reply to Lawrence Mandel [:lmandel] from comment #49) > Gerv - Given that this change has been backed out, can you please follow up > with Categorizr and 51Degrees to ensure they don't pick up this change? Done - emailed 51Degrees, and commented again at Categorizr. Gerv
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: