Moodle
  1. Moodle
  2. MDL-27793

Problem with translated terms for 'login name' with some themes

    Details

    • Testing Instructions:
      Hide

      (0) Install non english languages and RTL languages too as German or Spanish and Hebrew (rtl) logout and look at login page.

      Part A : left-to-right languages

      1)
      i) test that no clipping happens (as in screenshot) to long labels for ['username'] and ['password']. (you can also make the word there very long by editing the html or lang file)
      ii) test that no wrapping to those labels happen when the window is made smaller.

      2) test (1) in all core themes in the master branch. In master branch test also that the 'remember username' is centralized and doesn't wrap unnecessarily.

      3) test (1) in all core themes in affected stable branches. (if fix is applied there)

      4) include testing this in different browsers and at different screen resolution (From Sam's last peer-review comment)
      Part B : perform (1 - 3) but with RTL languages this time.
      (hint: lang/en/langconfig.php -> direction -> 'ltr' can be tweaked too)

      Show
      (0) Install non english languages and RTL languages too as German or Spanish and Hebrew (rtl) logout and look at login page. Part A : left-to-right languages 1) i) test that no clipping happens (as in screenshot) to long labels for ['username'] and ['password'] . (you can also make the word there very long by editing the html or lang file) ii) test that no wrapping to those labels happen when the window is made smaller. 2) test (1) in all core themes in the master branch. In master branch test also that the 'remember username' is centralized and doesn't wrap unnecessarily. 3) test (1) in all core themes in affected stable branches. (if fix is applied there) 4) include testing this in different browsers and at different screen resolution (From Sam's last peer-review comment) Part B : perform (1 - 3) but with RTL languages this time. (hint: lang/en/langconfig.php -> direction -> 'ltr' can be tweaked too)
    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE
    • Pull from Repository:
    • Pull Master Branch:
    • Rank:
      17445

      Description

      In German language 'login name' is one long word 'Anmeldename'. At login page some new themes set the description for the field on the left side, others put them on top the field. In German pages the theme cuts the last sign and the word is not complete. There are also other languages that use long terms but with several words (as in spanish).

      The area for the word should be wider and we don't get problems. Generally the place should be wide enough to add each term. Also the two lines in spanish don't look good.

      1. anomaly.png
        35 kB
      2. ff_m21_formal_white.png
        72 kB
      3. ff_m22_master_formal_white.png
        72 kB
      4. ie8_im22_formal_white.png
        56 kB
      5. ie8_m21_formal_white_1px_indent.png
        49 kB
      6. login.png
        61 kB
      7. m21_m22_master_anomaly_ie8.png
        8 kB

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this.

          I've put it on our backlog and we'll try to get to it as soon as we can.

          In the meantime adding more information, such as replication instructions, fix test instructions, a workaround or even a code solution, will help us and other users.

          Show
          Michael de Raadt added a comment - Thanks for reporting this. I've put it on our backlog and we'll try to get to it as soon as we can. In the meantime adding more information, such as replication instructions, fix test instructions, a workaround or even a code solution, will help us and other users.
          Hide
          Martin Dougiamas added a comment -

          Yes, we need a generic solution here that always looks good with words of any length, and we need it to work across all themes by default.

          Show
          Martin Dougiamas added a comment - Yes, we need a generic solution here that always looks good with words of any length, and we need it to work across all themes by default.
          Hide
          Phil added a comment -

          It seems that in the current theme, .loginform (which contains the labels) has a set width of 175px which is too narrow for some languages.
          I would replace that with a min-width of 300px. We could go further and reduce the labels' line-height so that if in extreme cases it were still to happen, it would still look presentable.
          More generally the .loginform has a set width of 100% in the base core.css file, but to avoid the current issue (which happens when the window is shrinked horizontally, under 1060px), it would behave better with a min-width of 300px.

          Show
          Phil added a comment - It seems that in the current theme, .loginform (which contains the labels) has a set width of 175px which is too narrow for some languages. I would replace that with a min-width of 300px. We could go further and reduce the labels' line-height so that if in extreme cases it were still to happen, it would still look presentable. More generally the .loginform has a set width of 100% in the base core.css file, but to avoid the current issue (which happens when the window is shrinked horizontally, under 1060px), it would behave better with a min-width of 300px.
          Hide
          Michael de Raadt added a comment -

          Hi, Phil.

          The CSS min-width property is not supported in IE before IE8. Could you propose another alternative?

          Michael;

          Show
          Michael de Raadt added a comment - Hi, Phil. The CSS min-width property is not supported in IE before IE8. Could you propose another alternative? Michael;
          Hide
          Phil added a comment -

          I think this one would work down to IE7 included if a fixed width was specified as well.
          The simplest alternative would be to give .loginform a width of 300px.
          But since in the core.css file it has a width of 100%, the best solution would be for the latter not be overridden in children themes.

          Show
          Phil added a comment - I think this one would work down to IE7 included if a fixed width was specified as well. The simplest alternative would be to give .loginform a width of 300px. But since in the core.css file it has a width of 100%, the best solution would be for the latter not be overridden in children themes.
          Hide
          Ralf Hilgenstock added a comment -

          Hi Phil,

          why didn't you give .loginform a relative width of 50%. An alternative for this page could be to set labels in a separate line.

          We get the same problem in several pages opened from administration block.
          Ralf

          Show
          Ralf Hilgenstock added a comment - Hi Phil, why didn't you give .loginform a relative width of 50%. An alternative for this page could be to set labels in a separate line. We get the same problem in several pages opened from administration block. Ralf
          Hide
          Aparup Banerjee added a comment -

          +1 for having the labels in separate lines.

          This way the width for strings can be maximized and yet we can have a consistent look and feel. Keeping this simpler would make it easier for themes i'd imagine.

          I've also noticed that the 'forgot password' area is wrapping unnecessarily in the login page from the screenshot.
          hm, looking at how separate lines would look like across all the other core themes..

          Show
          Aparup Banerjee added a comment - +1 for having the labels in separate lines. This way the width for strings can be maximized and yet we can have a consistent look and feel. Keeping this simpler would make it easier for themes i'd imagine. I've also noticed that the 'forgot password' area is wrapping unnecessarily in the login page from the screenshot. hm, looking at how separate lines would look like across all the other core themes..
          Hide
          Aparup Banerjee added a comment -

          Hi Sam,
          could you review this please?

          btw, is there any reason why wrapping of the forgotpass link wasn't fixed in the stable branches but only in master?

          Show
          Aparup Banerjee added a comment - Hi Sam, could you review this please? btw, is there any reason why wrapping of the forgotpass link wasn't fixed in the stable branches but only in master?
          Hide
          Aparup Banerjee added a comment -

          note: patch isn't about putting labels on separate lines.

          I've worked out a way to have labels on the same line but not allow clipping of the labels. What this means is that the text will grow towards the direction away from the input box.

          I've done this using css direction (set to opposite the current languages's direction) and setting overflow to visible. This way the text will overflow but in the opposite direction of the language therefore not getting clipped under the input box.

          Sam did mention concern for affects on screen readers reading direction so i ran a test on the screen reader Orca (on ubuntu) by setting
          lang/en/langconfig.php : $string['thisdirection'] = 'rtl'; to 'rtl' and orca seems to not care about the css direction. Orca still read the english fine even if direction for the label was set to Right-to-left. Hence i'm inclined to think that screen readers shouldn't be affected too much.

          Show
          Aparup Banerjee added a comment - note: patch isn't about putting labels on separate lines. I've worked out a way to have labels on the same line but not allow clipping of the labels. What this means is that the text will grow towards the direction away from the input box. I've done this using css direction (set to opposite the current languages's direction) and setting overflow to visible. This way the text will overflow but in the opposite direction of the language therefore not getting clipped under the input box. Sam did mention concern for affects on screen readers reading direction so i ran a test on the screen reader Orca (on ubuntu) by setting lang/en/langconfig.php : $string ['thisdirection'] = 'rtl'; to 'rtl' and orca seems to not care about the css direction. Orca still read the english fine even if direction for the label was set to Right-to-left. Hence i'm inclined to think that screen readers shouldn't be affected too much.
          Hide
          Sam Hemelryk added a comment -

          Hi Apu,

          I've been looking at this now.
          It gets a passive +1 from me - I'm not 100% that we should backport this to stable branches.

          I've checked the theme's within master and while there are a couple of very minor differences that wouldn't be noticed I'm sure so +1 there, however its a +0.5 for backporting - we'd have to test the existing 20 theme's thoroughly as there are changes that have landed for theme's in 21 and master only.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Apu, I've been looking at this now. It gets a passive +1 from me - I'm not 100% that we should backport this to stable branches. I've checked the theme's within master and while there are a couple of very minor differences that wouldn't be noticed I'm sure so +1 there, however its a +0.5 for backporting - we'd have to test the existing 20 theme's thoroughly as there are changes that have landed for theme's in 21 and master only. Cheers Sam
          Hide
          Aparup Banerjee added a comment -

          I've tested with all themes in master and stable branches and I've made a few more tweaks in attempts to centralize the loginbox position across themes. in RTL and LTR.

          Sending for integration ( but feel free to have a look again and add your thoughts Sam )

          Show
          Aparup Banerjee added a comment - I've tested with all themes in master and stable branches and I've made a few more tweaks in attempts to centralize the loginbox position across themes. in RTL and LTR. Sending for integration ( but feel free to have a look again and add your thoughts Sam )
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Sorry but I really became surprised viewing that "dark-css-hackery" in action (inverting directions...) to get this addressed. Is it really necessary? Why?

          Perhaps an alternative route should be to rethink why the html in that page need that sort of adjustment and fix the page/form instead?

          I'd halt this for 1 more week considering other alternatives. I trust you that it works but... I don't like what I see (stating my CSS-knowledge is very basic, but...)

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Sorry but I really became surprised viewing that "dark-css-hackery" in action (inverting directions...) to get this addressed. Is it really necessary? Why? Perhaps an alternative route should be to rethink why the html in that page need that sort of adjustment and fix the page/form instead? I'd halt this for 1 more week considering other alternatives. I trust you that it works but... I don't like what I see (stating my CSS-knowledge is very basic, but...) Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I'm reopening this for another round... IMO we should explore other ways to fix this, let's discuss it.

          Thanks and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - I'm reopening this for another round... IMO we should explore other ways to fix this, let's discuss it. Thanks and ciao
          Hide
          Aparup Banerjee added a comment - - edited

          yep agreed its a little dark. maybe its only for master?

          The basic problem here and with many areas of css is that we don't know the width of the content we're rendering, therefore its already been a hack all along to guess the width proportions between Left(labels) and Right (inputs) side. An easy way would be to set the login boxes to be vertically separate , thus able to utilise any needed widths upto 100% but this already exists in canvas based themes. I don't know how important it is to keep these differences between base and canvas themes but if we want to preserve the slight difference in themes, and not let stuff inadvertently overlap, we need to write from center outwards. (or find out content width before rendering?)

          The only issue I see here is what Sam brought up regarding screen readers, I've only tested that with the one i have (Orca in Ubuntu). I'm not sure how other possibly more clever ones will behave.

          That said I'm not CSS guru either lol, comments Sam ?

          Show
          Aparup Banerjee added a comment - - edited yep agreed its a little dark. maybe its only for master? The basic problem here and with many areas of css is that we don't know the width of the content we're rendering, therefore its already been a hack all along to guess the width proportions between Left(labels) and Right (inputs) side. An easy way would be to set the login boxes to be vertically separate , thus able to utilise any needed widths upto 100% but this already exists in canvas based themes. I don't know how important it is to keep these differences between base and canvas themes but if we want to preserve the slight difference in themes, and not let stuff inadvertently overlap, we need to write from center outwards. (or find out content width before rendering?) The only issue I see here is what Sam brought up regarding screen readers, I've only tested that with the one i have (Orca in Ubuntu). I'm not sure how other possibly more clever ones will behave. That said I'm not CSS guru either lol, comments Sam ?
          Hide
          Sam Hemelryk added a comment -

          Howdy

          I was talking to Eloy this morning about it.

          He was very concerned with the use of direction to control the overflow and to be truthful the more I look at it the less I like it as well. Even if it does the job the next person who reads the CSS is going to look at those rules - assume its a mistake or not needed and remove them (albeit it is a very smart solution to the problem).

          Either way after chatting with Eloy a bit about it we did decide that we should probably look for a better solution to the problem.
          Reading back through the issue I see that there are really two problems that have been raised:

          1. Long words (or things that can't be wrapped) get cut off because of overflow
          2. Multiple words get wrapped which doesn't look good.

          In regards to the two problems the first is really something that we should try to minimise and we can probably get through that by handling width and introducing minimum widths (just means we need to make sure things drop nicely when shrunk to that minimum width).
          The second problem when I think about it isn't really a problem - it's not necessarily nice when things wrap across lines but its unavoidable. Even if none of our language packs lead to it people can still choose to use their own strings in which case they can put anything in. By allowing wrapping we reduce our chances of hitting further overflow problems.

          Thinking about this and while talking to Eloy we discussed whether perhaps the solution lies in looking at the HTML as well as the CSS that is being produced by the login. Either way really I think Eloy is right we just need to look and see if there is a better solution that avoids any magic.

          Cheers
          Sam

          As for finding a solution to this in such as way I would start by looking at the login page HTML - if the CSS is really tricky then either we're trying to do something complex or as it is in our case given all we want is boxed information the HTML is wrong... well not so much wrong but could be improved.
          There shouldn't be anything wrong with content wrapping - it probably should anyway as people can use there own strings there if they like and there's no telling what people will put. Really we just need to minimise the need to wrap by increasing the width

          Show
          Sam Hemelryk added a comment - Howdy I was talking to Eloy this morning about it. He was very concerned with the use of direction to control the overflow and to be truthful the more I look at it the less I like it as well. Even if it does the job the next person who reads the CSS is going to look at those rules - assume its a mistake or not needed and remove them (albeit it is a very smart solution to the problem). Either way after chatting with Eloy a bit about it we did decide that we should probably look for a better solution to the problem. Reading back through the issue I see that there are really two problems that have been raised: Long words (or things that can't be wrapped) get cut off because of overflow Multiple words get wrapped which doesn't look good. In regards to the two problems the first is really something that we should try to minimise and we can probably get through that by handling width and introducing minimum widths (just means we need to make sure things drop nicely when shrunk to that minimum width). The second problem when I think about it isn't really a problem - it's not necessarily nice when things wrap across lines but its unavoidable. Even if none of our language packs lead to it people can still choose to use their own strings in which case they can put anything in. By allowing wrapping we reduce our chances of hitting further overflow problems. Thinking about this and while talking to Eloy we discussed whether perhaps the solution lies in looking at the HTML as well as the CSS that is being produced by the login. Either way really I think Eloy is right we just need to look and see if there is a better solution that avoids any magic. Cheers Sam As for finding a solution to this in such as way I would start by looking at the login page HTML - if the CSS is really tricky then either we're trying to do something complex or as it is in our case given all we want is boxed information the HTML is wrong... well not so much wrong but could be improved. There shouldn't be anything wrong with content wrapping - it probably should anyway as people can use there own strings there if they like and there's no telling what people will put. Really we just need to minimise the need to wrap by increasing the width
          Hide
          Urs Hunkler added a comment -

          For all my themes I decided to change the CSS to show the label above the input field. This is also common use in login forms and you don't have issues with the text length. Plus you can make the username field wider for those with long usernames - for example when you are forced to use your email for your username.

          Why not use this approach which also adds better usability to some users?

          Show
          Urs Hunkler added a comment - For all my themes I decided to change the CSS to show the label above the input field. This is also common use in login forms and you don't have issues with the text length. Plus you can make the username field wider for those with long usernames - for example when you are forced to use your email for your username. Why not use this approach which also adds better usability to some users?
          Hide
          Aparup Banerjee added a comment - - edited

          Hi Urs,
          Yes that's what i had thought of to do earlier but realized that all the canvas based themes already do that so i'm now trying to preserve the login page look in 'base' based themes. (bad idea?)

          ok guys, i'll put the dark fix in my dungeon. I'll be looking at improving the login page's Very embedded html code. Hopefully making it not so embedded inline too

          Show
          Aparup Banerjee added a comment - - edited Hi Urs, Yes that's what i had thought of to do earlier but realized that all the canvas based themes already do that so i'm now trying to preserve the login page look in 'base' based themes. (bad idea?) ok guys, i'll put the dark fix in my dungeon. I'll be looking at improving the login page's Very embedded html code. Hopefully making it not so embedded inline too
          Hide
          Michael de Raadt added a comment -

          Reverting the affected version as it was changed in error.

          Show
          Michael de Raadt added a comment - Reverting the affected version as it was changed in error.
          Hide
          Aparup Banerjee added a comment -

          ok I've had a chat with Eloy and Sam, it seems it might be agreeable to stick with the original solution using the css direction to control the overflow direction as long as there is an issue to deal with re-writing the login page (and removing the horrible embedded html+code) and properly taking care of this in master.

          Show
          Aparup Banerjee added a comment - ok I've had a chat with Eloy and Sam, it seems it might be agreeable to stick with the original solution using the css direction to control the overflow direction as long as there is an issue to deal with re-writing the login page (and removing the horrible embedded html+code) and properly taking care of this in master.
          Hide
          Aparup Banerjee added a comment -

          created MDL-29940 to look at login pages in master. Sam, if this looks ok (no changes) please feel free to send it up for integration.

          Show
          Aparup Banerjee added a comment - created MDL-29940 to look at login pages in master. Sam, if this looks ok (no changes) please feel free to send it up for integration.
          Hide
          Sam Hemelryk added a comment -

          Hi Apu,

          The changes look good.
          I'd put it up for integration now, then depending upon if you have time to look into a few things I'd suggest the following:

          1. Don't define two sets of rules based upon direction unless you really need to.
            In the case of the following:
            .dir-rtl .loginbox .loginform .form-label {width:47%;}
            .dir-ltr .loginbox .loginform .form-label {width:46%;}
            

            Try the following:

            .loginbox .loginform .form-label {width:46%;}
            .dir-rtl .loginbox .loginform .form-label {width:47%;}
            

            Here you are setting the default style and then overriding the rule especially for rtl languages.
            The advantage to doing this is that if for any reason that direction tag is not there or changes then things will continue to work in the default way. Having one less selector will also help performance and keeping things simple means that themer's wanting to change things round can do so easier.

          2. In respect to the above code do we need to set the widths differently there for rtl languages? Surely a single width is going to work in both cases. If its a problem caused by margins or padding or some such we should look to apply margins/padding evenly. Eitherway reducing the number of overrides we need for rtl is also a BIG advantage... complex CSS is almost always misunderstood.
          3. It would pay to improve the testing instructions to include testing this in different browsers and at different screen resolution. Note please that all of our theme's break 100% when using IE6/7 with RTL languages this is a known issue and will be solved hopefully in 2.2

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Apu, The changes look good. I'd put it up for integration now, then depending upon if you have time to look into a few things I'd suggest the following: Don't define two sets of rules based upon direction unless you really need to. In the case of the following: .dir-rtl .loginbox .loginform .form-label {width:47%;} .dir-ltr .loginbox .loginform .form-label {width:46%;} Try the following: .loginbox .loginform .form-label {width:46%;} .dir-rtl .loginbox .loginform .form-label {width:47%;} Here you are setting the default style and then overriding the rule especially for rtl languages. The advantage to doing this is that if for any reason that direction tag is not there or changes then things will continue to work in the default way. Having one less selector will also help performance and keeping things simple means that themer's wanting to change things round can do so easier. In respect to the above code do we need to set the widths differently there for rtl languages? Surely a single width is going to work in both cases. If its a problem caused by margins or padding or some such we should look to apply margins/padding evenly. Eitherway reducing the number of overrides we need for rtl is also a BIG advantage... complex CSS is almost always misunderstood. It would pay to improve the testing instructions to include testing this in different browsers and at different screen resolution. Note please that all of our theme's break 100% when using IE6/7 with RTL languages this is a known issue and will be solved hopefully in 2.2 Cheers Sam
          Hide
          Aparup Banerjee added a comment -

          Thanks Sam. (will look into this)

          Show
          Aparup Banerjee added a comment - Thanks Sam. (will look into this)
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi, I don't see the changes suggested by Sam here 1 & 2 above.

          Should I wait till then?

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Hi, I don't see the changes suggested by Sam here 1 & 2 above. Should I wait till then? Ciao
          Hide
          Aparup Banerjee added a comment -

          ah thats (1 & 2 ) done.

          btw, i tried rebasing and ran into conflicts that even when i tried resolving (basically took my changes over the others done) git would still say :
          "You must edit all merge conflicts and then
          mark them as resolved using git add"

          so Eloy, if it doesn't work for you feel free to reject till next (more) time :-|

          Show
          Aparup Banerjee added a comment - ah thats (1 & 2 ) done. btw, i tried rebasing and ran into conflicts that even when i tried resolving (basically took my changes over the others done) git would still say : "You must edit all merge conflicts and then mark them as resolved using git add" so Eloy, if it doesn't work for you feel free to reject till next (more) time :-|
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Oh, man, this change has accumulated with other 2 changes performed this week to some themes by MDL-22351 and MDL-29030 that already leaded to merge-conflict.

          So surely it's better to postpone it for next week, and redo the css changes on top. sounds ok?

          Show
          Eloy Lafuente (stronk7) added a comment - Oh, man, this change has accumulated with other 2 changes performed this week to some themes by MDL-22351 and MDL-29030 that already leaded to merge-conflict. So surely it's better to postpone it for next week, and redo the css changes on top. sounds ok?
          Hide
          Aparup Banerjee added a comment -

          yep will have to redo the css to check each theme's loginbox :-| , reopening.

          Show
          Aparup Banerjee added a comment - yep will have to redo the css to check each theme's loginbox :-| , reopening.
          Hide
          Michael de Raadt added a comment -

          Carrying this over to the next STABLE Sprint.

          Show
          Michael de Raadt added a comment - Carrying this over to the next STABLE Sprint.
          Hide
          Aparup Banerjee added a comment -

          finally back onto this

          Show
          Aparup Banerjee added a comment - finally back onto this
          Hide
          Aparup Banerjee added a comment -

          ok i've rebased my branches(alot of work fixing up themes (duplicate work) was also done by kordan after this was delayed). Conflicts are resolved. up for intergration.

          Show
          Aparup Banerjee added a comment - ok i've rebased my branches(alot of work fixing up themes (duplicate work) was also done by kordan after this was delayed). Conflicts are resolved. up for intergration.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Aparup Banerjee added a comment -

          thanks, rebased.

          Show
          Aparup Banerjee added a comment - thanks, rebased.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated, thanks! (21, 22 & master).

          Plz, test this specially for all themes/browsers under stables!

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated, thanks! (21, 22 & master). Plz, test this specially for all themes/browsers under stables!
          Hide
          Rossiani Wijaya added a comment -

          Hi Apu,

          Some feedback on testing this issue for all branches (M21, M22, master):
          rtl:

          • ff: anomaly (attachment: anomaly.png)
          • ie8: all themes, even in standard

          ltr:
          ie8: anomaly, spacious gap between username and input text (attachment: m21_m22_master_anomaly_ie8.png)

          I'm not sure if this is intention or bug for formal_white theme (4 screenshots).

          Apu mentioned that RTL issue should be fixed on separate tracker issue to avoid further conflict within the theme. I agree with him and fine to pass this issue.

          Apu take a look the bugs above and let me know how you want to handle this.

          Show
          Rossiani Wijaya added a comment - Hi Apu, Some feedback on testing this issue for all branches (M21, M22, master): rtl: ff: anomaly (attachment: anomaly.png) ie8: all themes, even in standard ltr: ie8: anomaly, spacious gap between username and input text (attachment: m21_m22_master_anomaly_ie8.png) I'm not sure if this is intention or bug for formal_white theme (4 screenshots). Apu mentioned that RTL issue should be fixed on separate tracker issue to avoid further conflict within the theme. I agree with him and fine to pass this issue. Apu take a look the bugs above and let me know how you want to handle this.
          Hide
          Aparup Banerjee added a comment -

          Thanks Rossie,

          ff: anomaly (attachment: anomaly.png) --> that means the widths there are now incorrect - i'm now thinking about stable though - not sure if its ok to pass for stable.

          ie8 - i hate ie but thanks for testing on ie , did it work before? anyway i'd fail fail this to be fixed up further - especially since its affecting stable..

          Show
          Aparup Banerjee added a comment - Thanks Rossie, ff: anomaly (attachment: anomaly.png) --> that means the widths there are now incorrect - i'm now thinking about stable though - not sure if its ok to pass for stable. ie8 - i hate ie but thanks for testing on ie , did it work before? anyway i'd fail fail this to be fixed up further - especially since its affecting stable..
          Hide
          Rossiani Wijaya added a comment -

          Failing issue.

          Show
          Rossiani Wijaya added a comment - Failing issue.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          24h countdown before reverting this begins now (agreed with Aparup via private chat).

          23:59:59
          23:59:58
          ..
          ..

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - 24h countdown before reverting this begins now (agreed with Aparup via private chat). 23:59:59 23:59:58 .. .. Ciao
          Hide
          Aparup Banerjee added a comment -

          nono! the blue wire! not the red wire!

          Show
          Aparup Banerjee added a comment - nono! the blue wire! not the red wire!
          Hide
          Aparup Banerjee added a comment - - edited

          ok heres an update:

          • "ltr: ie8: anomaly, spacious gap between username and input text (attachment: m21_m22_master_anomaly_ie8.png)"
            • that's been improved but was space was there pre-patch.

          commit branches (same as issue branches) have all been updated with one more commit:
          please pick
          master : diff @ https://github.com/nebgor/moodle/compare/mistress...MDL-27793 - new commit is https://github.com/nebgor/moodle/commit/1e4fab8b619f3c8ed715794a3c403f1affd6f264
          22 : diff @ https://github.com/nebgor/moodle/compare/MOODLE_22_STABLE...MDL-27793_m22 - new commit is https://github.com/nebgor/moodle/commit/148e9e46b8997d0fd2ee0f745b6c9deb52744196
          21: diff @ https://github.com/nebgor/moodle/compare/MOODLE_21_STABLE...MDL-27793_m21 - new commit is https://github.com/nebgor/moodle/commit/df28c9a6057b7a91a65fb3672561d01eda1be3d0

          • loginbox not showing up in rtl with completely disastrous invisible out of sight login boxes
            • is an existing issue for blocks as well @ MDL-26400
          Show
          Aparup Banerjee added a comment - - edited ok heres an update: "ltr: ie8: anomaly, spacious gap between username and input text (attachment: m21_m22_master_anomaly_ie8.png)" that's been improved but was space was there pre-patch. commit branches (same as issue branches) have all been updated with one more commit: please pick master : diff @ https://github.com/nebgor/moodle/compare/mistress...MDL-27793 - new commit is https://github.com/nebgor/moodle/commit/1e4fab8b619f3c8ed715794a3c403f1affd6f264 22 : diff @ https://github.com/nebgor/moodle/compare/MOODLE_22_STABLE...MDL-27793_m22 - new commit is https://github.com/nebgor/moodle/commit/148e9e46b8997d0fd2ee0f745b6c9deb52744196 21: diff @ https://github.com/nebgor/moodle/compare/MOODLE_21_STABLE...MDL-27793_m21 - new commit is https://github.com/nebgor/moodle/commit/df28c9a6057b7a91a65fb3672561d01eda1be3d0 loginbox not showing up in rtl with completely disastrous invisible out of sight login boxes is an existing issue for blocks as well @ MDL-26400
          Hide
          Rossiani Wijaya added a comment -

          Latest patch works great Apu (for LTR )

          Issue with RTL probably should be address together in MDL-26400 and push this for this week integration.

          Show
          Rossiani Wijaya added a comment - Latest patch works great Apu (for LTR ) Issue with RTL probably should be address together in MDL-26400 and push this for this week integration.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Last commit cherry-picked to 21, 22 & master. So ready for final testing round.

          Thanks!

          PS: I found the commit message in 21_STABLE really curious with one "Conflicts" note within it.

          Show
          Eloy Lafuente (stronk7) added a comment - Last commit cherry-picked to 21, 22 & master. So ready for final testing round. Thanks! PS: I found the commit message in 21_STABLE really curious with one "Conflicts" note within it.
          Hide
          Aparup Banerjee added a comment -

          Thanks to rosie for all the great testing!

          Show
          Aparup Banerjee added a comment - Thanks to rosie for all the great testing!
          Hide
          Rossiani Wijaya added a comment -

          It all looks good.

          PS: just wanted to re-state that RTL issue will be address on MDL-26400.

          Thanks everyone.

          Test passed.

          Show
          Rossiani Wijaya added a comment - It all looks good. PS: just wanted to re-state that RTL issue will be address on MDL-26400 . Thanks everyone. Test passed.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Well,

          I wish I said it every time
          you do the things you do.
          You always lend a helping hand,
          and I'm filled with gratitude.

          You are strong and generous
          for each and everyone one of us.
          I am eternally grateful,
          I cannot say thanks enough.

          Sorry for the (un)cool bit above, lol. Closing this as fixed. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Well, I wish I said it every time you do the things you do. You always lend a helping hand, and I'm filled with gratitude. You are strong and generous for each and everyone one of us. I am eternally grateful, I cannot say thanks enough. Sorry for the (un)cool bit above, lol. Closing this as fixed. Ciao

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: