Add showfor support for Firefox OS

VERIFIED FIXED in 2013Q4

Status

support.mozilla.org
Knowledge Base Software
P2
normal
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: atopal, Assigned: mythmon)

Tracking

unspecified
2013Q4
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=wiki p=5 s=2013.21)

(Reporter)

Description

5 years ago
Firefox OS versions can be identified by their Gecko version number. They are documented here:
https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference#Firefox_OS

We should break out 1.0, 1.1 and 1.2 for now:
They follow the following pattern as described at the MDN page above:

1.0 Mozilla/5.0 (Mobile; nnnn; rv:18.0) Gecko/18.0 Firefox/18.0
1.1 Mozilla/5.0 (Mobile; nnnn; rv:18.1) Gecko/18.1 Firefox/18.1
1.2 Mozilla/5.0 (Mobile; nnnn; rv:26.0) Gecko/26.0 Firefox/26.0

The nnnn part is optional, we could use it to detect the manufacturer, once manufacturers
According to the emails I've seen on b2g lists, it's a *bad* thing that manufacturers are adding stuff to the user agent. I'm +1 on avoiding using that.

The version thing is super helpful, though. I'll write up a bug to look into using that on Input, too.
This is likely going to be a huge pain to implement. I don't even know how to estimate it. I don't think it is possible to predect all the issues we will run into, so it probably makes sense for somebody to just iteratively hack on it outside of the sprints until it is done.

We might want to look into moving all this out of config.py into the DB while we are at it.

Are we sure FxOS versions will always have a 1:1 mapping to a Gecko/FF version?
(Reporter)

Comment 3

5 years ago
Huh, somehow my last sentence got cut off. What I meant is "once manufacturers actually use it and we need to distinguish devices".

Will, yeah, the page mentions the same thing. As far as I can tell it's not really used so far (but I don't have all handsets). Also, we don't have much device specific content as far as I know. So we can just skip that for now, and cross that bridge once we get to it.

Ricky, I think we can be reasonably sure, if the train model holds. Each new version of Firefox OS should be built on top of a new Firefox version. I don't think there is a guarantee though. Maybe Michelle can shed some light on it?

Re moving this into the DB. I guess that would be bug 768244? Should that bug block this one?

On how to implement this: Your call. Feel free to take it out of the sprint, but we should make sure it gets dev time allocated in each sprint. Maybe this could be a tracker and we spawn a research bug first?
Before doing anything with showfor, we need to have our javascript/qunit tests running again.
Depends on: 915708
as per "Firefox/firefoxversion is an optional compatibility token" i would avoid keying off of "firefoxversion" and instead key off of  "geckoversion". I would also get a "+1" on our parsing of the UA string from lawrence mandel who takes care of the UA string stuff (including the MDN page) and understands the nuances and what could break in the future.
(Reporter)

Comment 6

5 years ago
Thanks for the pointer, Roland. I asked Lawrence to shed some light on that.
It is unfortunate that Mozilla's own support system needs to rely on UA detection in order to effectively deliver targeted content to users. Unfortunate but not all that unexpected. Our message to web developers, which we share widely, is to use feature detection instead of UA detection as it is the future proof method for web development.

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #2)
> Are we sure FxOS versions will always have a 1:1 mapping to a Gecko/FF
> version?

That looks to be the plan but I don't know that you can rely on that 100%. For ex, Firefox OS 1.1 was to ship with the same version of Gecko as Firefox OS 1.0.1 - version 18.0. For Web compatibility reasons (namely, the addition of support for h.264 playback by general Web content and file upload support) we incremented the version to 18.1.

I certainly don't know all of the details of how SUMO customizes content for users. I would like to see if it is possible to move SUMO to a model where articles are displayed based on the capabilities of the device. For ex, if a device does not support h.264 playback by general Web content SUMO may display articles that highlight the limitation to the user. I would guess that this type of change would be rather invasive and require a re-architecture of the SUMO site and the structure of its content. Not something to be taken lightly. (I would be happy to be corrected about this point.)

I'm happy to have a conversation about practical short term strategies to meet the needs of SUMO and long term planning to move towards a sustainable approach.
pushing this out to the next sprint so we can start looking into it. Assigning to :mythmon.
Assignee: nobody → mcooper
Priority: P3 → P2
Summary: Add showfor support for Firefox OS → [research] Add showfor support for Firefox OS
Whiteboard: u=user c=wiki p= s=2013.20 → u=user c=wiki p= s=2013.21
(Assignee)

Comment 9

5 years ago
:lmandel: The adage of "don't UA sniffing, use feature detection" is for doing things like serving mobile content, or denying users from using a site ("your browser doesn't support html5 webaudio, this site won't work"). Doing that by UA sniffing is bad, and UA sniffing in general is basically impossible for all browsers.

But that is not what we are doing here. We are teaching people how to use the *UI* of the browser, for the most part. Consider the article about hiding a tab bar with only one tab[0]. It lists instructions for how to install an addon to add an addon that implements an option that was removed in Firefox 23. This is something that feature detection cannot do, unless you want to use feature detection to fingerprint Firefox 23 and above, which is like identifying people based on SAT scores instead of asking them for their name. Lets not do that.

I agree, for most purposes, UA sniffing is bad, because you don't actually want to know the version of the browser, you want to know the features they support. Most websites don't need to know what version of Firefox you have, they just need to know what you support. For SUMO, we really do want to know what version you are running, and we need to vary our content based on that. We aren't writing documentation about web features. We are writing documentation about Firefox. This UA sniffing *is* our sustainable approach.

Regarding relying on Gecko version corresponding to particular versions of Firefox: I talked to some people at Summit, and they seemed quite confident that FxOS would follow a 12 week train model, and so would consistently have the expected version of Gecko, *starting with FxOS 1.2*. 1.0 and 1.1 to unexpected versions mainly so that the developers and carriers could work against a stable target instead of a moving one. We should be able to rely on the train model from here on out.

[0]: https://support.mozilla.org/en-US/kb/how-hide-tab-strip-when-you-only-have-one-tab
Making this 5pts to block off ~half of :mythmon's time during the sprint. This can be adjusted and replaced by followups if that makes sense.
Whiteboard: u=user c=wiki p= s=2013.21 → u=user c=wiki p=5 s=2013.21
:mythmon - Thank you for the detailed response and clear example. It seems that to meet the current SUMO needs, knowledge of the OS or app version is required. I do not have an alternative method to suggest at this point. I have added this use case the the UA detection use cases list. https://wiki.mozilla.org/UA/UseCases#Specific_Device.2FUI_Determination_for_Documentation
(Assignee)

Updated

5 years ago
Blocks: 929126
(Assignee)

Comment 12

5 years ago
I looked around at showfor, and here is my list of things to do to get this done (not ordered):

* Update browserdetect.js to understand FxOS.
* Update wiki config data (__init__.py) to include FxOS data.
* Update showfor.js to add options to the dropdowns for the new data, and showfar parsing for it.
* Check that showfor.py and the wikiparser deal with this new data correctly.
* Add tests for all of the above, including Qunit for front end.

I think that this is ready to go. I'm going to start working on implementing this, so I'm removing the [research] tag.
Summary: [research] Add showfor support for Firefox OS → Add showfor support for Firefox OS
(Assignee)

Comment 13

5 years ago
I dove into this. Turns out, that I underestimated the scope of what I was working on; now I appreciate r1cky's 5pt estimate. The interaction of mobile and desktop is not simple to start with, and adding Firefox OS to the mix makes it a little crazy. I have a proposal that might work, and I'm curious to get some feedback about it. I'd guess I'm about 1/4 of the way done implementing this:

I've come up with an idea that can handle having multiple products per article, and deals with scenarios like an article that deals with transferring music from a laptop to a Firefox OS phone, and so needs to vary on both the OS of the laptop and the version of Firefox OS.

Right now, each article has a number of products it is applicable to. I've also added the idea that products have platforms and versions. For example, Firefox (the desktop browser), has several platforms, including Windows 7, Windows 8, Mac, and Linux. It also has several versions like 24, 17 ESR, and 27. Firefox for Android on the other hand, only has one platform, Android, but still has many versions. Some products, like Webmaker, don't have versions or platforms. For my data model, I faked it and said they have one version, version 0, and one platform, the web.

Using this, I've changed showfor to work on each product, instead of just on version and on platform. For example, consider an article that is written for Firefox for Android, and changes based on the version. For this article, I would show a version selector for Firefox for Android, like so: http://i.imgur.com/IIRtgdk.png .

Now consider an article that is relevant for both Firefox for Android, Firefox OS, and Firefox Desktop, but doesn't change based on the version of any of these. This would simply show checkboxes to pick which platform is relevant. Of course. If the article also varied by version, it would show version select boxes, and look something like this: http://i.imgur.com/WyvgzEr.png

The UX for this is a bit rough right now. All of this would try to pick sane defaults based on the useragent, like we do now. Additionally, I hope to be able to hide UI elements that don't do anything, such as removing the version selector if the article doesn't vary by the version of Firefox. This a stretch goal though, so it might not work out.

I'm interested in feedback from people who write and read articles on this. Would this work? Is it too complicated? Is it not flexible enough? I think that it will make showfor simpler, from a development point of view, but I might be wrong about that.

Redoing showfor this way should make bug 768244 (Adding Thunderbird support) pretty easy.
Flags: needinfo?(a.topal)
(Reporter)

Updated

5 years ago
Flags: needinfo?(mverdi)
(Reporter)

Comment 14

5 years ago
I love this, Mike! Most of the time the selector will be invisible to users and they shouldn't need to care anyway, if we implement good defaults. However things are getting more complicated for us with more products and platforms and this approach looks like it would work great. I'm mostly just localizing articles, so feedback from Michael would probably be most appropriate here.
Flags: needinfo?(a.topal)

Comment 15

5 years ago
(In reply to Mike Cooper [:mythmon] from comment #13)
> I dove into this. Turns out, that I underestimated the scope of what I was
> working on; now I appreciate r1cky's 5pt estimate. The interaction of mobile
> and desktop is not simple to start with, and adding Firefox OS to the mix
> makes it a little crazy. I have a proposal that might work, and I'm curious
> to get some feedback about it. 

Thanks Mike! This is the way we've always wanted it to work but I don't think it was considered because it was always too much (would have required the who products infrastructure as a prerequisite).

> 
> I've come up with an idea that can handle having multiple products per
> article, and deals with scenarios like an article that deals with
> transferring music from a laptop to a Firefox OS phone, and so needs to vary
> on both the OS of the laptop and the version of Firefox OS.
> 
> Right now, each article has a number of products it is applicable to. I've
> also added the idea that products have platforms and versions. For example,
> Firefox (the desktop browser), has several platforms, including Windows 7,
> Windows 8, Mac, and Linux. It also has several versions like 24, 17 ESR, and
> 27. Firefox for Android on the other hand, only has one platform, Android,
> but still has many versions. Some products, like Webmaker, don't have
> versions or platforms. For my data model, I faked it and said they have one
> version, version 0, and one platform, the web.
> 

Cool. I'm with you.

> Using this, I've changed showfor to work on each product, instead of just on
> version and on platform. For example, consider an article that is written
> for Firefox for Android, and changes based on the version. For this article,
> I would show a version selector for Firefox for Android, like so:
> http://i.imgur.com/IIRtgdk.png .
> 
> Now consider an article that is relevant for both Firefox for Android,
> Firefox OS, and Firefox Desktop, but doesn't change based on the version of
> any of these. This would simply show checkboxes to pick which platform is
> relevant. Of course. If the article also varied by version, it would show
> version select boxes, and look something like this:
> http://i.imgur.com/WyvgzEr.png
> 

Leaving the selector UI aside for a moment, here's how I understanding it working automatically for regular sumo visitors looking for help:
Desktop user visits an article. The "desktop sections" are customized for their OS and Firefox version. The "Android sections" show the default Android version and Firefox version. The "Firefox OS sections" show the default Firefox OS version.

Android user visits an article. The "desktop sections" show the default OS and Firefox version. The "Android sections" are customized for their version of Android and Firefox. The "Firefox OS sections" show the default Firefox OS version.

FxOS user visits an article. The "desktop sections" show the default OS and Firefox version. The "Android sections" show the default Android version and Firefox version. The "Firefox OS sections" are customized for their version of Firefox OS.


> The UX for this is a bit rough right now. All of this would try to pick sane
> defaults based on the useragent, like we do now. Additionally, I hope to be
> able to hide UI elements that don't do anything, such as removing the
> version selector if the article doesn't vary by the version of Firefox. This
> a stretch goal though, so it might not work out.

I think working out the UI for the switcher and hiding elements that don't do anything should be part of the goal, not a stretch. Editors, reviewers, localizers and forum helpers rely on this UI every day. Let's get Bram on this.


> 
> Redoing showfor this way should make bug 768244 (Adding Thunderbird support)
> pretty easy.

Bonus!!

Thanks,
Michael
Flags: needinfo?(mverdi)
(Assignee)

Comment 16

5 years ago
> Leaving the selector UI aside for a moment, here's how I understanding it working automatically for regular sumo visitors looking for help:
> Desktop user visits an article. The "desktop sections" are customized for their OS and Firefox version. The "Android sections" show the default Android version and Firefox version. The "Firefox OS sections" show the default Firefox OS version.

That would indeed be the case, for articles that are marked as support all of the respective OSes. For articles only marked as applying to Firefox for Desktop, the Android and Firefox OS selectors won't exist at all, since they are not relevant.

> I think working out the UI for the switcher and hiding elements that don't do anything should be part of the goal, not a stretch. Editors, reviewers, localizers and forum helpers rely on this UI every day. Let's get Bram on this.

To be clear, if an article is only marked as support for Firefox Desktop, only that set of selectors will be shown - Firefox OS selectors won't be shown. It is easy to do this part of the UI. The stretch goal I was talking about was reading through the document and noticing things like an article that changes depending on what version of Firefox the user has, but not what OS they have. On this article, the OS selector could be hidden. This is quite a bit smarter than the current showfor. If you still think this is a "must have", that's ok. I just want to be clear what I was calling a stretch goal. I think it is a great idea to get some UI and/or UX insight on these selectors. Right now my prototypes aren't very clear.

Another note: you mentioned multiple version of Android, but we don't currently support this anywhere on SUMO, mainly because we can't automatically detect it. The change I'm proposing would make it easy to add showfor support for these platforms in the documents, but it wouldn't help users if we can't detect it. I think that multiple Android versions is out of scope right now.

Comment 17

5 years ago
(In reply to Mike Cooper [:mythmon] from comment #16)
 
> To be clear, if an article is only marked as support for Firefox Desktop,
> only that set of selectors will be shown - Firefox OS selectors won't be
> shown. It is easy to do this part of the UI. The stretch goal I was talking
> about was reading through the document and noticing things like an article
> that changes depending on what version of Firefox the user has, but not what
> OS they have. On this article, the OS selector could be hidden. This is
> quite a bit smarter than the current showfor. 

Ok. The situation where we change the desktop instructions for Fx versions and not OSs is pretty rare (maybe non-existent) right now. In the future this should change. With Australis, all OSs will have the same menu panel which will (finally) make some instructions unified across OSs. Of course it will take a while for everyone to upgrade...

> 
> Another note: you mentioned multiple version of Android, but we don't
> currently support this anywhere on SUMO, mainly because we can't
> automatically detect it. The change I'm proposing would make it easy to add
> showfor support for these platforms in the documents, but it wouldn't help
> users if we can't detect it. I think that multiple Android versions is out
> of scope right now.

Yep. Sorry - getting ahead of myself. :)
(Assignee)

Comment 18

5 years ago
Ricky gave me the good idea of making a simple demo to play around with the new showfor so that people besides me could easily test it. So I did it. It turned out to be a lot easier than I expected, which was fun. So, if you are interested in the new showfor, please visit the below link and try it. You can type {for} syntax into the left box, and it will appear in the middle as rendered html. It only supports {for}, none of the other wiki syntax. It will live update, which I think is really cool. If you are at a loss for things to type in, I've also attached my showfor torture test that I've been using



Showfor demo: https://rawgithub.com/mythmon/kitsune/fxos-showfor-915686/kitsune/sumo/static/showfordemo.html
Showfor test article: https://gist.github.com/mythmon/7236259
(Reporter)

Comment 19

5 years ago
I have done some quick testing of the demo and it looks really good. Didn't run into any issues, but I don't have a battery of edge cases etc. It might be useful to get QA involved before we roll this out. Mike, can you already tell when this would be ready to be QAed?
Flags: needinfo?(mcooper)
(Assignee)

Comment 20

5 years ago
My goal is to have this ready to deploy on Thursday, so it can sit on stage all weekend and get a lot of eyeballs. I'm not sure if that works well for QA or not.
Flags: needinfo?(mcooper)
In order to test this, QA will need details on what needs to be tested. As I'm not overly familiar with this feature, it's not a good idea to rely on me to get a full list of edge cases. Also, we may need to enlist other QA folks if this has a short release timeline as I'm OOO on Friday, and the weekend isn't a good option. 

That being said, I'll take a look at the demo and start working on this.
(Assignee)

Comment 22

5 years ago
This doesn't have to go out this weekend. I am hoping to have it ready by then, but if we need more time QAing in order for everyone to feel good about this, it can wait longer. SUMO just has some difficulties with keeping things on stage for a long time, so we might need to get creative.
(Reporter)

Comment 23

5 years ago
Since Michael won't have time to look at this before next week we should definitely wait with the deployment. In the mean time we can start assembling the testing plan.
On staging I see two sets of Example Instructions on this page: 
https://support.allizom.org/en-US/kb/new-showfor-test-article-1/edit

Checking the template, I am getting data shown {for fx21} and {for not fx21}. Checked using Mac + Version 25FF. No changes when switching FF version. Only one set of instructions shown on prod.
On staging I now see numbering on the Table of Contents for all articles, which is not on prod.
On staging, selecting any version of FFOS other than 1.1 will not keep choice after page refresh- it always returns to Version 1.1.
Clarification: All version dropdowns do not keep selection [Firefox, FF Android or FFOS]
All checkboxes for Customize this Article also lose edits
(Reporter)

Comment 29

5 years ago
On iOS7 using Safari I'm seeing all content when it should only show the default platform and the default product version. Works on production.
(Reporter)

Comment 30

5 years ago
Same with Firefox on Firefox OS.
(Assignee)

Comment 31

5 years ago
Status:

Comment 24 - {fx 21} selectors working improperly. I was incorrectly not including the metadata for hidden versions on the page, so showfor used the fallback behavior for anything related to versions less than 23 that were not 17. I think I have this fixed, and am pushing out a fix shortly.

Comment 25 - I changed the way tocs are hidden and show. If you look on prod, you might notice that the numbers show briefly before being hidden. I think the reason they were hidden before is because renumbering the TOC to match the headers would be confusing, and so would leaving gaps in the numbering. Easy fix.

Comment 26 through 30 - I'll be working on this next.

Comment 29 and 30 - Troubling. I'm not sure why this is happening. I'll look into it.


Next steps: fixing the UI state, then removing the TOC numbering, then looking into FxOS and IOS breakage.
When a user has a version of Firefox that is not listed on the dropdown, the default is Version 25. The content displays correctly for the version [I used FF22]. This is not necessarily a bug, but the expected behavior is not obvious.
Verified that user no longer gets duplicate {for} data, however I'm seeing the *wrong* {for} data. It has {for fx21} data instead of {for not fx21}.

article: https://support.allizom.org/en-US/kb/new-showfor-test-article-1#firefox:mac:fx25

Example Instructions line 1: On the menu bar, click on the History menu, and select Clear Recent History....

From the clearCacheCookies template: 
Expected: {for not fx21}
{for mac}On the menu bar, click on the {menu Tools} menu, and select {menu Clear Recent History...}.{/for}


ACTUAL: {for fx21}
{for mac}On the menu bar, click on the {menu History} menu, and select {menu Clear Recent History...}.{/for}
Please ignore comment 33, I misunderstood. I see now that {for fx21} = fx21 and greater.
(Assignee)

Comment 35

5 years ago
I have fixes for the TOC numbers and showing weird versions in the selectboxes (if a user running Firefox 19 visits the site, an option will be added to the selectbox for them).

I haven't looked into the iOS or FxOS stuff yet.

I can't deploy this to stage because something is wrong with Chief right now.
(Assignee)

Comment 36

5 years ago
Yay. Thanks to :solarce, this got deployed. The Redis for chief got sad. :solarce made Redis happy again.
On stage I see the fix for TOC numbers. However, using a non-listed FF version [19,22], I do not see an option added to the selectbox.
(Assignee)

Comment 38

5 years ago
Rebecca: I think I know what is going on with the non-listed FF versions. On startup, showfor decided what state to put you in (browser/version/platform) based on one of three criteria: first url, second a sessionStorage setting (like localStorage, but temporary), and finally your useragent. I think this will make things nicer for people using one Firefox to debug another, but it does make it harder to test showfor. To get around this, you can easily clear this. In the JS console (ctrl+shift+k on windows/linux), run this line:

    sessionStorage.removeKey('showfor::persist')

Since the sessionStorage key overrides the useragent, if you use a user agent switcher, you will confuse it. I should have thought to mention this sooner, it might have made testing easier.
The TOC fix only shows for desktop - I see the numbers on FFOS & Android versions of stage.

Also, the user agent info in Comment 38 makes sense- thanks.
(Assignee)

Comment 40

5 years ago
I just pushed out a change that makes showfor work on mobile. It turned out to be something pretty trivial. I also fixed the TOC numbers on mobile too.

I think this is the last of the problems that I know about regarding showfor. If there is anything else, please let me know!
Status: NEW → ASSIGNED
(Assignee)

Comment 41

5 years ago
I was talking with Ricky, Rehan, and Will earlier, and we came to the conclusion that we probably shouldn't deploy this tomorrow, even if it is ready, because of US Thanksgiving, which all of the devs will be partipating in. I didn't think about the calendar when I talked about deploying this tomorrow.

Lets hold off deploying this until Monday, Dec 2nd at the earliest. Sorry for more delays, i just want to avoid breaking anything!
(Reporter)

Comment 42

5 years ago
Right, US holidays. This is a big change and even after lots of testing there is a chance it might break things. Since there is no hard deadline for us I see no problem with deferring this to Monday 2nd. Michael?
Flags: needinfo?(mverdi)

Comment 43

5 years ago
Deferring to Monday works for me.
Flags: needinfo?(mverdi)
(Assignee)

Comment 44

5 years ago
I have a fix for the problem rbillings found with viewing articles not relavent to Firefox OS on a Firefox OS device. Another pretty simple fix. This isn't deployed yet because of more Chief errors. I am told that top men are on it.
Verified TOC fix, and Windows only info displays on mobile [FFOS, Android].
Current staging environment shows FF Version 25 when using FF19, 22, 23... Utilizing thesessionStorage.removeItem('showfor::persist') command didn't help this time.
(Reporter)

Comment 47

5 years ago
We have reports that showfor does not respect right to left languages. I'm not exactly sure how to test that. Rebecca, can you help with that?
(Assignee)

Comment 48

4 years ago
Kadir, what do you mean about RTL languages? I took a quick look at one of our demo articles in Hebrew (a RTL language), and didn't see anything obviously wrong. This isn't a translated document, but it does show everything in a RTL way, even though it is English.

Showfor Demo in Hebrew: https://support.allizom.org/he/kb/new-showfor-test-article-1
(Reporter)

Comment 49

4 years ago
Mike, my comment is based on this comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=939832#c11

Amir says "3-When i write tags in articles(such as {for fx17} and others, which are left-to right, this tags don't show correctly in right-to-left text."

As it stands that wouldn't be a regression/showstopper, just something we might need to address soon.
Kadir- I'm afraid I don't see the RTL issue either. The showfor sidebar displays correctly [on the right], the dropdowns are correct. Even on mobile & /he it looks correct.
Also, verified that FF versions are displaying correctly on stage, in reference to comment 46.
(Assignee)

Comment 52

4 years ago
Rebecca: I *just* pushed the fix for FF versions and was about to come comment to tell you about. Nice timing.

I also can't find anything wrong with RTL. Unless someone can provide more specific details besides "It doesn't work", I'm going to consider that WORKSFORME.
Outside of the RTL issue, I believe everything is tested & ready to go.

Comment 54

4 years ago
(In reply to Kadir Topal [:atopal] from comment #47)
> We have reports that showfor does not respect right to left languages. I'm
> not exactly sure how to test that. Rebecca, can you help with that?

Translate one of the test articles into Arabic and just preview it: https://support.allizom.org/ar/kb/new-showfor-test-article-1/translate#preview You can see that the showfor is broken.
(In reply to Verdi [:verdi] from comment #54)
> (In reply to Kadir Topal [:atopal] from comment #47)
> > We have reports that showfor does not respect right to left languages. I'm
> > not exactly sure how to test that. Rebecca, can you help with that?
> 
> Translate one of the test articles into Arabic and just preview it:
> https://support.allizom.org/ar/kb/new-showfor-test-article-1/
> translate#preview You can see that the showfor is broken.

I don't think it is RTL specific, the same thing happens in Spanish:
https://support.allizom.org/es/kb/new-showfor-test-article-1/translate

I think the translate page is missing the showfor form or something critical for showfor to work properly.
Also, the create a new KB article and edit KB article pages have the same issue:
https://support.allizom.org/en-US/kb/new
https://support.allizom.org/en-US/kb/new-showfor-test-article-1/edit

Now I'm thinking it might just be related to preview.
(Reporter)

Comment 57

4 years ago
Fresh out of the go/nogo meeting. Mike will fix the preview issue, Rebecca and Michael will verify and we'll roll out at that point.
(Assignee)

Comment 58

4 years ago
Issues got fixed, they got thumbs up and r+ed from Rebecca and Ricky, respectively.

This landed on master in these 4 commits

    ae04740 Remove sourcemap error from jquery.
    bab758b [Bug 915686] The great showfor rewrite of 2013.
    a1d2e57 [Bug 915686] Make browserdetect.js understand fxos
    bb8b624 Fix up qunit tests.

I just pushed this to production, and I checked that stage appears to work. \o/

Let the follow up bugs begin!
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Verified showfor content matches UA, content changes with dropdowns, content is correct, TOC is correct, looks good on a variety of FF & mobile combos, preview works well. Looks good!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.