In Chrome 6 on Mac I found the dashboad is not working as it should. When I drag items to and from the regions and back to the area of available blocks items loose this sizing.

I think a picture describes it best. http://img.skitch.com/20100922-mh1grw7wnmjux52jhggd43ip4h.png

I was not able to reproduce this in Safari.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

reglogge’s picture

Title: The Dashboard Drag and Drop is broken in Chrome » The Dashboard Drag and Drop is broken in most browsers
FileSize
68.87 KB
76.3 KB

I can reproduce this in Safari also. In Firefox it looks still different. Both are the Mac versions. Screens attached.

The reason seems to lie in the fact that menu blocks are automatically expanded upon placing them in a dashboard region, showing their menu entries. When putting them back in the tray, somehow this expanded state is retained which leads to these effects.

But is this critical? Since a simple page refresh solves this issue, I'm not sure that it qualifies. The functionality is still there, it just looks odd.

ksenzee’s picture

Priority: Critical » Normal

Definitely not critical.

franz’s picture

I had the same issue on Firefox 3.6.9 on Linux

franz’s picture

Actually, just open the customize interface and drag blocks around those disabled. This is enough to reproduce. It doesn't appear to be related to actually dragging the block to a region.

droplet’s picture

dragged icon has contextual-links to configure it. does it by design ??

Jody Lynn’s picture

Title: The Dashboard Drag and Drop is broken in most browsers » Dashboard disabled blocks change size and can lose titles when dragged
Priority: Normal » Major
Status: Active » Needs review

The problem was that we were ending up with an extra nested block div due to the js using html() instead of replaceWith() to replace the newly loaded block. Also we should not have been using ajax to load the block when it was moving around in the disabled section and had not yet been enabled.

Another problem was that if you had a disabled block like 'Search' (which by default has no title) and you moved it into the enabled blocks, there would be no title, and you could end up with empty blocks in the disabled section.

Patch fixes both these problems.

Jody Lynn’s picture

FileSize
2.55 KB
aspilicious’s picture

Status: Needs review » Needs work
FileSize
20.13 KB

Srry for this...
Waiting for this patch for a long time :)

Jody Lynn’s picture

I don't really understand what's happening in that screenshot, but I'll see if I can reproduce. Which block are you dragging there in English (or does it happen for every block)?

yoroy’s picture

That's the recent comments block there.

aspilicious’s picture

Srry for the dutch screenshot...
I talked with jody on irc, she is going to reroll.

Jody Lynn’s picture

Status: Needs work » Needs review
FileSize
4.16 KB

Ok, new patch fixes this and also avoids loading already fully-loaded blocks more than once.

aspilicious’s picture

Status: Needs review » Needs work

Not yet completly good :(
Thnx for your efforts btw.

I think it looks better if we delete the width part from the over event.
And put item.css('width', ''); on the start event. Than the width doesn't flikker all around.
Tested this myself, and I prefer it.
(and it would look nicer if we could copy the style from the disabled block, that way we always have the same style for dragged blocks)

Also, if you select a block (for example recent comments) close to the right upper corner of the block the border appears again o_O.
Afterwards it doesn't go away while dragging.

Jody Lynn’s picture

I'm not sure if those problems are related to this issue though.

The display of the block while dragging should be a separate issue (unless it's different with this patch applied). Can you confirm if any of these problems were introduced by this patch?

aspilicious’s picture

Also, if you select a block (for example recent comments) close to the right upper corner of the block the border appears again o_O.
Afterwards it doesn't go away while dragging.

I think this is introduced by this issue.
Not sure, no time for testing.

sun’s picture

Version: 7.x-dev » 8.x-dev
Priority: Major » Normal
Issue tags: +Needs backport to D7

Like @ksenzee, I also don't think this is more severe than normal. Needs to go into D8 first.

Jody Lynn’s picture

Status: Needs work » Needs review
FileSize
4.18 KB

I rerolled the patch.

I took a deeper look into it, and can confirm that the issues aspilicious mentions are unrelated to this patch. The issue described with the 'border when hovering over the top right' is due to contextual activating, which is the same before and after the patch (see #831088: Contextual links are showing for disabled dashboard blocks).

kscheirer’s picture

Issue tags: -Needs backport to D7

#18: 919290-18.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, 919290-18.patch, failed testing.

droplet’s picture

doesn't it remove from D8 ?

marcingy’s picture

Version: 8.x-dev » 7.x-dev

This module no longer exists in d8