Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-43723

Users drag&drop the blocks instead of scrolling up/down.

    Details

    • Story Points (Obsolete):
      8
    • Sprint:
      FRONTEND Sprint 10

      Description

      When the blocks are displayed at the bottom of the pages (small screen) it's causing critical UX issues:

      • the drag and drop is triggered but the user only wants to scroll down.
      • when the user wants to drag and drop a block, he has hard time to move the block up or down.
      • the block drag and drop on Android is buggy.

      We just need to switch to the none AJAX version of the feature or display the accessible menu.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            jerome Jérôme Mouneyrac added a comment -

            done

            Show
            jerome Jérôme Mouneyrac added a comment - done
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Hi Jerome.

            I've just being looking this over now.

            Your solution here appears to work well, there are a couple of code points I noted that I will mention later, however first there is one thing about this design that I do not know about.
            At present block regions are always initialised for drag+drop, and then the handles are added and removed depending on the width of the blocks to the screen.
            This allows for drag+drop to work when the user resizes their browser.
            However it seems to me that we are then initialising a lot of JS for someone using a small screen that they will likely never use remembering that really only developers will resize their browsers.
            As a developer I like what you've done, but I wonder whether we'd be much better off measuring block - screen width once and making the decision once. If the block region is nearly full screen drag and drop gets disabled.
            This will be less convienient for developers but will likely result in a better experience for end users as there will be less JS in play for them.
            Anyway, just my thoughts on that matter, definitely I would say get in Andrew Nicols to look over it.

            As for code heres what I've noted:

            1. update_block_header_ajax_support: you should add the new variables to the var statement at the top.
            2. update_block_header_ajax_support: one('.'CSS.BLOCK).one('.'+CSS.HEADER) is the same as one('.'+CSS.BLOCK' .'+CSS.HEADER)
            3. update_block_header_ajax_support: When measuring the block width it would probably be easier and just as safe to measure the region width e.g. blockwidth = this.regionobjects[regionname].node.get('offsetWidth') (really this just saves DOM queries)
            4. update_block_header_ajax_support: window.innerWidth is not supported by all browsers. YUI has a .get('winWidth') that you can call on any node that you should use instead.
            5. update_block_header_ajax_support: Have you considered using document width rather than window width. On themes like standard that scroll horizontally on report layouts you may get false positives. Truthfully I think those false positives probably lead to a better outcome but its still worth mentioning I think.
            6. update_block_header_cursor: I don't like that you make the same checks here as you do in update_block_header_ajax_support. Looking at the code I think you'd be better off converting that cursor to CSS (who knows why it isn't thats just dumb). Add a class to the block region when drag and drop is active (remove it when you remove the handle etc) and then style the cursor on the class. That would be a much better solution in general.

            Cheers
            Sam

            Show
            samhemelryk Sam Hemelryk added a comment - Hi Jerome. I've just being looking this over now. Your solution here appears to work well, there are a couple of code points I noted that I will mention later, however first there is one thing about this design that I do not know about. At present block regions are always initialised for drag+drop, and then the handles are added and removed depending on the width of the blocks to the screen. This allows for drag+drop to work when the user resizes their browser. However it seems to me that we are then initialising a lot of JS for someone using a small screen that they will likely never use remembering that really only developers will resize their browsers. As a developer I like what you've done, but I wonder whether we'd be much better off measuring block - screen width once and making the decision once. If the block region is nearly full screen drag and drop gets disabled. This will be less convienient for developers but will likely result in a better experience for end users as there will be less JS in play for them. Anyway, just my thoughts on that matter, definitely I would say get in Andrew Nicols to look over it. As for code heres what I've noted: update_block_header_ajax_support: you should add the new variables to the var statement at the top. update_block_header_ajax_support: one('.' CSS.BLOCK).one('.'+CSS.HEADER) is the same as one('.'+CSS.BLOCK ' .'+CSS.HEADER) update_block_header_ajax_support: When measuring the block width it would probably be easier and just as safe to measure the region width e.g. blockwidth = this.regionobjects [regionname] .node.get('offsetWidth') (really this just saves DOM queries) update_block_header_ajax_support: window.innerWidth is not supported by all browsers. YUI has a .get('winWidth') that you can call on any node that you should use instead. update_block_header_ajax_support: Have you considered using document width rather than window width. On themes like standard that scroll horizontally on report layouts you may get false positives. Truthfully I think those false positives probably lead to a better outcome but its still worth mentioning I think. update_block_header_cursor: I don't like that you make the same checks here as you do in update_block_header_ajax_support. Looking at the code I think you'd be better off converting that cursor to CSS (who knows why it isn't thats just dumb). Add a class to the block region when drag and drop is active (remove it when you remove the handle etc) and then style the cursor on the class. That would be a much better solution in general. Cheers Sam
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            Thanks Sam I'll fix the coding issues you reported. About the solution itself:

            Without my patch: the AJAX drag and drop for blocks is enabled on all screens/all devices.
            With my patch: when a block is taking the full width of the screen, then the AJAX drag and drop is removed to avoid bad behaviour on touch screens.
            With Sam's suggestion: same solution but except checking each block, do it for all blocks at once. I didn't implement it because some people like to move their blocks from left to right / right to left. So it's a dilemma, I picked the solution with which I think users will report less issues. With both solutions users will report new issues. We will redesign the bocks on mobile entirely in the coming year(s) and probably on desktop too.
            I suggest we implement the per-block solution as it works well and hopefully will go unnoticed by users.

            Show
            jerome Jérôme Mouneyrac added a comment - - edited Thanks Sam I'll fix the coding issues you reported. About the solution itself: Without my patch: the AJAX drag and drop for blocks is enabled on all screens/all devices. With my patch: when a block is taking the full width of the screen, then the AJAX drag and drop is removed to avoid bad behaviour on touch screens. With Sam's suggestion: same solution but except checking each block, do it for all blocks at once. I didn't implement it because some people like to move their blocks from left to right / right to left. So it's a dilemma, I picked the solution with which I think users will report less issues. With both solutions users will report new issues. We will redesign the bocks on mobile entirely in the coming year(s) and probably on desktop too. I suggest we implement the per-block solution as it works well and hopefully will go unnoticed by users.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            Some points I didn't change:
            1. I kept dragdelegations variable below the regionobjects variable because they are related.
            3. as the problem comes from the header I check the header node width and not the entire node width.
            5. thanks for mentioning it as I didn't think about the horizontal scrollbar. As you mention, the outcome is better so I don't change it.
            6. I'm not sure it's a good idea to let the theme developer tweak the cursor in the CSS. It's currently not possible to tweak the cursor and it would not be good to encourage it now as the blocks are going to be redesigned.

            PS: Andrew mentioned to me quickly to check the Y.throttle function. I understand the benefit (http://www.nczonline.net/blog/2007/11/30/the-throttle-function/) but I don't think the user will see any difference and without it it's less code to maintain and easier to read. Of course I may not see the nasty stuff, I'll be happy to fix it if I understand them.

            Show
            jerome Jérôme Mouneyrac added a comment - Some points I didn't change: 1. I kept dragdelegations variable below the regionobjects variable because they are related. 3. as the problem comes from the header I check the header node width and not the entire node width. 5. thanks for mentioning it as I didn't think about the horizontal scrollbar. As you mention, the outcome is better so I don't change it. 6. I'm not sure it's a good idea to let the theme developer tweak the cursor in the CSS. It's currently not possible to tweak the cursor and it would not be good to encourage it now as the blocks are going to be redesigned. PS: Andrew mentioned to me quickly to check the Y.throttle function. I understand the benefit ( http://www.nczonline.net/blog/2007/11/30/the-throttle-function/ ) but I don't think the user will see any difference and without it it's less code to maintain and easier to read. Of course I may not see the nasty stuff, I'll be happy to fix it if I understand them.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            Sending for integration.

            PS: 2.5 code is a slightly different from 2.6 as drag-gable icons were not displayed in 2.5.

            Show
            jerome Jérôme Mouneyrac added a comment - Sending for integration. PS: 2.5 code is a slightly different from 2.6 as drag-gable icons were not displayed in 2.5.
            Hide
            cibot CiBoT added a comment -

            Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!

            Show
            cibot CiBoT added a comment - Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!
            Hide
            stronk7 Eloy Lafuente (stronk7) added a comment -

            Side comment: Please, please, provide better commit messages (formatting). It's a pain to read them that way. TIA!

            Show
            stronk7 Eloy Lafuente (stronk7) added a comment - Side comment: Please, please, provide better commit messages (formatting). It's a pain to read them that way. TIA!
            Hide
            damyon Damyon Wiese added a comment -

            My first thoughts on this is - are we tied to the idea of draggable block headers? This is the only place in moodle we allow drag and drop on anything but a drag handle. We still have the drag handles for blocks in the page (for the keyboard version) - if we just restrict the drag to operating on the drag handles we will solve more problems than just this one (affects MDL-42955 just from current integration list).

            Can we discuss this as a possible solution?

            Show
            damyon Damyon Wiese added a comment - My first thoughts on this is - are we tied to the idea of draggable block headers? This is the only place in moodle we allow drag and drop on anything but a drag handle. We still have the drag handles for blocks in the page (for the keyboard version) - if we just restrict the drag to operating on the drag handles we will solve more problems than just this one (affects MDL-42955 just from current integration list). Can we discuss this as a possible solution?
            Hide
            phalacee Jason Fowler added a comment -

            I agree with Damyon's idea of using the same system through out moodle, the rest of the system uses an icon to initiate drag. I've always found it odd that blocks didn't do the same.

            Show
            phalacee Jason Fowler added a comment - I agree with Damyon's idea of using the same system through out moodle, the rest of the system uses an icon to initiate drag. I've always found it odd that blocks didn't do the same.
            Hide
            damyon Damyon Wiese added a comment -

            Reopening this, because I think restricting the drag to the drag handle is the correct solution, but I want to give others time to give their opinions too.

            Show
            damyon Damyon Wiese added a comment - Reopening this, because I think restricting the drag to the drag handle is the correct solution, but I want to give others time to give their opinions too.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            I first thought that people would complain more to have the drag feature remove from the headers. But after Damyon explained his opinion I think that keeping the drag feature on the icon only is a better solution than my current patch. The drag feature would be consistent everywhere in Moodle and I guess people would trigger the drag feature accidentally on touch screen quite rarely.

            +1 for the drag&drop feature on the icon only (we remove the drag&drop feature from the headers)

            Show
            jerome Jérôme Mouneyrac added a comment - I first thought that people would complain more to have the drag feature remove from the headers. But after Damyon explained his opinion I think that keeping the drag feature on the icon only is a better solution than my current patch. The drag feature would be consistent everywhere in Moodle and I guess people would trigger the drag feature accidentally on touch screen quite rarely. +1 for the drag&drop feature on the icon only (we remove the drag&drop feature from the headers)
            Hide
            cibot CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            cibot CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            dobedobedoh Andrew Nicols added a comment -

            Adding Ruslan as a watcher to this issue since he wrote the functionality in the first place.

            If my memory serves me correctly, part of the reasoning for making the header draggable was because the drag/drop icon is just too small to be realistically usable - it's only 12px.

            I think we should consider this sizing as part of the issue as a 12px icon is very touch unfriendly, and we are trying to find a solution with touch-screen devices specifically in mind.

            Show
            dobedobedoh Andrew Nicols added a comment - Adding Ruslan as a watcher to this issue since he wrote the functionality in the first place. If my memory serves me correctly, part of the reasoning for making the header draggable was because the drag/drop icon is just too small to be realistically usable - it's only 12px. I think we should consider this sizing as part of the issue as a 12px icon is very touch unfriendly, and we are trying to find a solution with touch-screen devices specifically in mind.
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            imo the tinier, the better, this issue is about to avoid to trigger the drag feature in favor of been able to scroll the screen (on touch screen). Sending it to peer-review.

            Show
            jerome Jérôme Mouneyrac added a comment - - edited imo the tinier, the better, this issue is about to avoid to trigger the drag feature in favor of been able to scroll the screen (on touch screen). Sending it to peer-review.
            Hide
            dobedobedoh Andrew Nicols added a comment -

            IMO you're wrong It still needs to be able to perform its designed function too!

            Show
            dobedobedoh Andrew Nicols added a comment - IMO you're wrong It still needs to be able to perform its designed function too!
            Hide
            cibot CiBoT added a comment -

            Results for MDL-43723

            • Remote repository: git://github.com/mouneyrac/moodle.git
            Show
            cibot CiBoT added a comment - Results for MDL-43723 Remote repository: git://github.com/mouneyrac/moodle.git Remote branch MDL-43723 -26 to be integrated into upstream MOODLE_26_STABLE Executed job http://integration.moodle.org/job/Precheck%20remote%20branch/750 Details: http://integration.moodle.org/job/Precheck%20remote%20branch/750/artifact/work/smurf.html Remote branch MDL-43723 -master-nomerge to be integrated into upstream master Executed job http://integration.moodle.org/job/Precheck%20remote%20branch/751 Details: http://integration.moodle.org/job/Precheck%20remote%20branch/751/artifact/work/smurf.html
            Hide
            damyon Damyon Wiese added a comment -

            My suggestion is to test it on some real phones and see if it's hard to click.

            Show
            damyon Damyon Wiese added a comment - My suggestion is to test it on some real phones and see if it's hard to click.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            it's not harder to click than all other existing icons in Moodle that have the exact same size... for sure

            Show
            jerome Jérôme Mouneyrac added a comment - it's not harder to click than all other existing icons in Moodle that have the exact same size... for sure
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Hi Jerome - my thoughts:

            This is considered a bug, a fix for 25, 26 and master should be found.
            25 and 26 I would guess need a solution as described by the title of this block.
            Master using the drag icon is nicer than dragging by the header.
            Resizing the move icon means resizing all of the block action icons as they're all that small, this change makes good sense but is master only (because it will cause theme regressions).

            So:

            • Your 26 solution, you still need to disable the header as a drag handle on small screens. Then backport to 25.
            • Master you solution is nice, but we need to decide if we increase all icon sizes now or in a separate issue. I vote separate issue as there is going to be a lot of theme tweaking etc (2.7 blocker obviously).

            Cheers
            Sam

            Show
            samhemelryk Sam Hemelryk added a comment - Hi Jerome - my thoughts: This is considered a bug, a fix for 25, 26 and master should be found. 25 and 26 I would guess need a solution as described by the title of this block. Master using the drag icon is nicer than dragging by the header. Resizing the move icon means resizing all of the block action icons as they're all that small, this change makes good sense but is master only (because it will cause theme regressions). So: Your 26 solution, you still need to disable the header as a drag handle on small screens. Then backport to 25. Master you solution is nice, but we need to decide if we increase all icon sizes now or in a separate issue. I vote separate issue as there is going to be a lot of theme tweaking etc (2.7 blocker obviously). Cheers Sam
            Hide
            jerome Jérôme Mouneyrac added a comment -

            I suggest we just check a hardcoded small screen size (the same than bootstrap) =>

            • drag&drop feature behaves the same in every branches (we'll let another issue deal with a redesign of the all drag&drop problems in Moodle) => easier to maintain later.
            • we do not change the current behavior except for phones (small screens) => not disturbing for users.
            • it will work on 99% of the phones even though the small size variable may be different (but it is unlikely that theme designers decide to overrule the bootstrap decision on what is a small screen) => fix the reported problem.
            Show
            jerome Jérôme Mouneyrac added a comment - I suggest we just check a hardcoded small screen size (the same than bootstrap) => drag&drop feature behaves the same in every branches (we'll let another issue deal with a redesign of the all drag&drop problems in Moodle) => easier to maintain later. we do not change the current behavior except for phones (small screens) => not disturbing for users. it will work on 99% of the phones even though the small size variable may be different (but it is unlikely that theme designers decide to overrule the bootstrap decision on what is a small screen) => fix the reported problem.
            Hide
            damyon Damyon Wiese added a comment -

            I agree with Sam - but I don't understand Jeromes last comment at all.

            Show
            damyon Damyon Wiese added a comment - I agree with Sam - but I don't understand Jeromes last comment at all.
            Hide
            dobedobedoh Andrew Nicols added a comment -

            To be honest, I'd rather we kept a consistent interface and just killed off the drag/drop on the header for all devices. I'd just prefer it if we made the drag icon larger too though to make it easier to pick up.

            I'm not keen on doing different things for different sized devices - if a theme chooses a different size for the media queries, we'll see a lot of quirkiness!

            Show
            dobedobedoh Andrew Nicols added a comment - To be honest, I'd rather we kept a consistent interface and just killed off the drag/drop on the header for all devices. I'd just prefer it if we made the drag icon larger too though to make it easier to pick up. I'm not keen on doing different things for different sized devices - if a theme chooses a different size for the media queries, we'll see a lot of quirkiness!
            Hide
            jerome Jérôme Mouneyrac added a comment -

            I suggested:

            • no branch difference (change behavior on master only when there is a real UX study about drag&drop is done)
            • the fix should be simply checking if the screen is small (against an hardcoded variable having same value than in bootstrap). If the screen is small then we disable drag&drop feature.
            Show
            jerome Jérôme Mouneyrac added a comment - I suggested: no branch difference (change behavior on master only when there is a real UX study about drag&drop is done) the fix should be simply checking if the screen is small (against an hardcoded variable having same value than in bootstrap). If the screen is small then we disable drag&drop feature.
            Hide
            damyon Damyon Wiese added a comment -

            I would agree to using the drag/drop handle only (not the entire header) on stables - but not changing the icon size. That should be a separate issue and master only.

            Then it is the same on all branches.

            -1 for checking if it is a small screen and doing something special.

            Show
            damyon Damyon Wiese added a comment - I would agree to using the drag/drop handle only (not the entire header) on stables - but not changing the icon size. That should be a separate issue and master only. Then it is the same on all branches. -1 for checking if it is a small screen and doing something special.
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            It's the current patch Damyon.

            The 2.5 case is a little bit different:
            On 2.5 stable there is no move icon. Only the header is draggable on 2.5.

            Show
            jerome Jérôme Mouneyrac added a comment - - edited It's the current patch Damyon. The 2.5 case is a little bit different: On 2.5 stable there is no move icon . Only the header is draggable on 2.5.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            Another existing design flaw to take in consideration, the Add block has no icons at all but it can be moved around by dragging the header. Disable JS, it cannot be moved anymore...

            Show
            jerome Jérôme Mouneyrac added a comment - Another existing design flaw to take in consideration, the Add block has no icons at all but it can be moved around by dragging the header. Disable JS, it cannot be moved anymore...
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            To summarize the issue.

            Issue
            When scrolling down/up on a touch screen, the user sometimes (especially on phones) triggers the block drag and drop ajax feature.

            To take in consideration

            • On 2.5 stable there is no move icon when the drag and drop ajax feature is enabled. You can only move it by the header when JS is enabled.
            • On every branches, you can move "Add block" block with the ajax header drag and drop, but there is not icon to move it neither in the ajax version, neither in the no-js version.
            • On my home, there is not ajax drag and drop for centred blocks (but there is ajax drag and drop for pre/post blocks). Centred blocks can only be moved with the no-ajax move icon that is displayed in both JS and no-JS UI. Note that once you move a centred block in pre/post region, then you can not move it back in the centered region with the ajax drag and drop feature.
            • it has been noticed that it would be better to have a bigger icon to trigger the move feature.
            • it is recommended to have a consistent behaviour over the branches.
            • it is recommended to not change the existing behaviour especially in stable branches.
            • a block redesign is planned for after 2.7.
            • it is most likely looking at the way drag and drop works, that the drag and drop question should be brainstormed too.

            Suggested solutions

            a) kill off the drag/drop on the header for small screen size only. All branches should behave the same.

            b) kill off the drag/drop on the header for all screen size. All branches should behave the same.

            c) kill off the drag/drop on the header for all screen size on master only. Killed off the drag/drop on the header for small screen size only on stable branches.

            About killing off the drag/drop on the header, we found two approaches:

            • check window width against a hard-coded variable - the same value as in bootstrap. If true then all blocks have their drag/drop on the header killed off.
            • check blocks width. If the block width is more than 80% of the window, then it is likely that this block is going to trigger the issue. Only matching blocks should have their drag/drop on the header killed off.

            Other mentioned tasks (do we create separate issue for them?):

            • Change the move (and other) icon(s) size.
            • Add the move icon on 2.5 stable.
            • Add move icon to "Add block".

            PS: I wrote a forum post about this issue.

            Show
            jerome Jérôme Mouneyrac added a comment - - edited To summarize the issue. Issue When scrolling down/up on a touch screen, the user sometimes (especially on phones) triggers the block drag and drop ajax feature. To take in consideration On 2.5 stable there is no move icon when the drag and drop ajax feature is enabled. You can only move it by the header when JS is enabled. On every branches, you can move "Add block" block with the ajax header drag and drop, but there is not icon to move it neither in the ajax version, neither in the no-js version. On my home, there is not ajax drag and drop for centred blocks (but there is ajax drag and drop for pre/post blocks). Centred blocks can only be moved with the no-ajax move icon that is displayed in both JS and no-JS UI. Note that once you move a centred block in pre/post region, then you can not move it back in the centered region with the ajax drag and drop feature. it has been noticed that it would be better to have a bigger icon to trigger the move feature. it is recommended to have a consistent behaviour over the branches. it is recommended to not change the existing behaviour especially in stable branches. a block redesign is planned for after 2.7. it is most likely looking at the way drag and drop works, that the drag and drop question should be brainstormed too. Suggested solutions a) kill off the drag/drop on the header for small screen size only. All branches should behave the same. b) kill off the drag/drop on the header for all screen size. All branches should behave the same. c) kill off the drag/drop on the header for all screen size on master only. Killed off the drag/drop on the header for small screen size only on stable branches. About killing off the drag/drop on the header, we found two approaches: check window width against a hard-coded variable - the same value as in bootstrap. If true then all blocks have their drag/drop on the header killed off. check blocks width. If the block width is more than 80% of the window, then it is likely that this block is going to trigger the issue. Only matching blocks should have their drag/drop on the header killed off. Other mentioned tasks (do we create separate issue for them?): Change the move (and other) icon(s) size. Add the move icon on 2.5 stable. Add move icon to "Add block". PS: I wrote a forum post about this issue.
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            In order to make the issue move forward I'm sending my last fix to integration (the fix is doing what Damyon and Andrew N. agreed):
            b) kill off the drag/drop on the header for all screen size.

            I'd suggest to create issues for:

            • Change the move (and other) icon(s) size.
            • Add the move icon on 2.5 stable.
            • Add move icon to "Add block".
            Show
            jerome Jérôme Mouneyrac added a comment - - edited In order to make the issue move forward I'm sending my last fix to integration (the fix is doing what Damyon and Andrew N. agreed): b) kill off the drag/drop on the header for all screen size. I'd suggest to create issues for: Change the move (and other) icon(s) size. Add the move icon on 2.5 stable. Add move icon to "Add block".
            Hide
            cibot CiBoT added a comment -

            Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!

            Show
            cibot CiBoT added a comment - Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!
            Hide
            marina Marina Glancy added a comment -

            Hi Jerome, can you please change the issue summary (it is very confusing now because you accepted a different approach) and rebase branches? I'm reviewing and testing meanwhile. Thanks

            Show
            marina Marina Glancy added a comment - Hi Jerome, can you please change the issue summary (it is very confusing now because you accepted a different approach) and rebase branches? I'm reviewing and testing meanwhile. Thanks
            Hide
            marina Marina Glancy added a comment - - edited

            In Standard theme the header is still draggable
            as well as in all other base-based themes

            Show
            marina Marina Glancy added a comment - - edited In Standard theme the header is still draggable as well as in all other base-based themes
            Hide
            marina Marina Glancy added a comment -

            Reopening since Jerome said he won't be able to address comments in this integration cycle

            Show
            marina Marina Glancy added a comment - Reopening since Jerome said he won't be able to address comments in this integration cycle
            Hide
            jerome Jérôme Mouneyrac added a comment - - edited

            Thanks Marina. I'll have a look after working on Atto issues.

            I forgot to check the standard themes, I supposed these themes were using the same code lib/yui/build/moodle-core-blocks/moodle-core-blocks-min.js file. I'll check them. I updated title and test instructions.

            PS: I lowered the issue priority as it doesn't impact a majority of users (mainly teachers when they edit a course on a mobile device with the Clean theme) and it's not blocking their work execution.

            Show
            jerome Jérôme Mouneyrac added a comment - - edited Thanks Marina. I'll have a look after working on Atto issues. I forgot to check the standard themes, I supposed these themes were using the same code lib/yui/build/moodle-core-blocks/moodle-core-blocks-min.js file. I'll check them. I updated title and test instructions. PS: I lowered the issue priority as it doesn't impact a majority of users (mainly teachers when they edit a course on a mobile device with the Clean theme) and it's not blocking their work execution.
            Hide
            cibot CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            cibot CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            jerome Jérôme Mouneyrac added a comment -

            Sending back to integration, I ported the fix on the legacy javascript code used by standard.

            Show
            jerome Jérôme Mouneyrac added a comment - Sending back to integration, I ported the fix on the legacy javascript code used by standard.
            Hide
            stronk7 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
            stronk7 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
            cibot CiBoT added a comment -

            Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!

            Show
            cibot CiBoT added a comment - Moving this issue to current integration cycle, will be reviewed soon. Thanks for the hard work!
            Hide
            damyon Damyon Wiese added a comment -

            Thanks Jerome, this patch on it's own works well. I think it just needs to be held until the move icon is added to the "Add a block" block. If we don't do that we will be breaking functionality on stables while that other issue is being worked on. I created an issue for it and set it as a blocker of this. I think this branch is fine as is - it just needs to wait for that other issue before being integrated.

            Also - I think that the keyboard drag/drop handles are sufficiently complex / risky that they should not be backported to 25 and so it's also fine if this issue is not backported to 25.

            Reopening, please resubmit along with the blocker.

            Show
            damyon Damyon Wiese added a comment - Thanks Jerome, this patch on it's own works well. I think it just needs to be held until the move icon is added to the "Add a block" block. If we don't do that we will be breaking functionality on stables while that other issue is being worked on. I created an issue for it and set it as a blocker of this. I think this branch is fine as is - it just needs to wait for that other issue before being integrated. Also - I think that the keyboard drag/drop handles are sufficiently complex / risky that they should not be backported to 25 and so it's also fine if this issue is not backported to 25. Reopening, please resubmit along with the blocker.
            Hide
            damyon Damyon Wiese added a comment -

            Pulling this back into integration. It actually does not cause any regressions, moving the "Add a block" block does not do anything useful to begin with.

            Show
            damyon Damyon Wiese added a comment - Pulling this back into integration. It actually does not cause any regressions, moving the "Add a block" block does not do anything useful to begin with.
            Hide
            stronk7 Eloy Lafuente (stronk7) added a comment -

            Integrated (26 and master), thanks!

            (sent on behalf of Damyon)

            Show
            stronk7 Eloy Lafuente (stronk7) added a comment - Integrated (26 and master), thanks! (sent on behalf of Damyon)
            Hide
            skodak Petr Skoda added a comment -

            works as described, cheers

            Show
            skodak Petr Skoda added a comment - works as described, cheers
            Hide
            damyon Damyon Wiese added a comment -

            Parallel programmParallel programming is harding is hard

            Thanks for reporting/fixing/testing/improving Moodle. This issue has now been released.

            Show
            damyon Damyon Wiese added a comment - Parallel programmParallel programming is harding is hard Thanks for reporting/fixing/testing/improving Moodle. This issue has now been released.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  10/Mar/14

                  Agile