starred/koel-koel

Fork 0

mirror of https://github.com/koel/koel.git synced 2026-04-25 08:46:00 +03:00

[GH-ISSUE #455] Scrollable issue with Firefox #321

New issue

Closed

opened 2026-02-26 02:32:49 +03:00 by kerem · 13 comments

kerem commented

2026-02-26 02:32:49 +03:00

Owner

Originally created by @X-Ryl669 on GitHub (Sep 20, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/455

Not a very big issue, but with firefox, if you press the "down" key, the screen scrolls down a bit, breaking the nice layout of the app. I've tracked it down to div with id dragGhost. If I change to display: none (in addition to the second remark below) then there is no possible scroll anymore and the layout is perfect. Is there any reason for position:relative and not absolute ?

The later would remove it from the flow, and will not cause the layout to overflow (and yes, body has overflow: hidden, but it does not apply here).

And, the textarea with id copyAreamust have its style property bottom set (else it's not positioned correctly). I've set it to 1px and it fixed the scrolling issue.

So the changes required to remove that overflow are:

#dragGhost {
    position: absolute;
    top: 0px;
    left: -99999px;
}

#copyArea {
   bottom: 1px;
}

Originally created by @X-Ryl669 on GitHub (Sep 20, 2016). Original GitHub issue: https://github.com/koel/koel/issues/455 Not a very big issue, but with firefox, if you press the "down" key, the screen scrolls down a bit, breaking the nice layout of the app. I've tracked it down to div with id `dragGhost`. If I change to `display: none` (in addition to the second remark below) then there is no possible scroll anymore and the layout is perfect. Is there any reason for `position:relative` and not `absolute` ? The later would remove it from the flow, and will not cause the layout to overflow (and yes, body has `overflow: hidden`, but it does not apply here). **And**, the textarea with id `copyArea`must have its style property `bottom` set (else it's not positioned correctly). I've set it to `1px` and it fixed the scrolling issue. So the changes required to remove that overflow are: ``` #dragGhost { position: absolute; top: 0px; left: -99999px; } #copyArea { bottom: 1px; } ```

kerem closed this issue

2026-02-26 02:32:49 +03:00

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Sep 20, 2016):

@X-Ryl669 those changes don't seem to matter by me.

@BernardGoldberger commented on GitHub (Sep 20, 2016): @X-Ryl669 those changes don't seem to matter by me.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@phanan commented on GitHub (Sep 21, 2016):

position: absolute will break the drag functionality, at least in Firefox.

@phanan commented on GitHub (Sep 21, 2016): `position: absolute` will break the drag functionality, at least in Firefox.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 21, 2016):

Strange... It works for me on Firefox, the "1 song" green tag is displayed attached to the mouse position while dragging.
@bdgold: I don't understand your comment. Do you mean the changes don't work for you ?

@X-Ryl669 commented on GitHub (Sep 21, 2016): Strange... It works for me on Firefox, the "1 song" green tag is displayed attached to the mouse position while dragging. @bdgold: I don't understand your comment. Do you mean the changes don't work for you ?

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 21, 2016):

@phanan: Another solution seems to display: none it and change to display: inline-block upon drag start event (and back to display: none when dragging stop). The position: absolute, top, left however does not require any style change in the JS code and I think it's cleaner.

@X-Ryl669 commented on GitHub (Sep 21, 2016): @phanan: Another solution seems to `display: none` it and change to `display: inline-block` upon drag start event (and back to `display: none` when dragging stop). The `position: absolute, top, left` however does not require any style change in the JS code and I think it's cleaner.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Sep 21, 2016):

@X-Ryl669 correct, it didn't fix it by me.

@BernardGoldberger commented on GitHub (Sep 21, 2016): @X-Ryl669 correct, it didn't fix it by me.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 21, 2016):

@bdgold: You need to add these properties in the Firefox debugger at the right place (not in the code, since if they are loaded before the app's CSS style, they'll get overloaded by the app).

@X-Ryl669 commented on GitHub (Sep 21, 2016): @bdgold: You need to add these properties in the Firefox debugger at the right place (not in the code, since if they are loaded before the app's CSS style, they'll get overloaded by the app).

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 21, 2016):

Do you want to try a PR for this ?

@X-Ryl669 commented on GitHub (Sep 21, 2016): Do you want to try a PR for this ?

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Sep 21, 2016):

I changed the css in app.vue and then ran gulp, is that not the way to try it? I'm not very familiar with the firefox debugger.

@BernardGoldberger commented on GitHub (Sep 21, 2016): I changed the `css` in `app.vue` and then ran `gulp`, is that not the way to try it? I'm not very familiar with the firefox debugger.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Sep 21, 2016):

Do you want to try a PR for this ?

Why not? it can always be rejected ;-) , and I can then test it as well.

@BernardGoldberger commented on GitHub (Sep 21, 2016): > Do you want to try a PR for this ? Why not? it can always be rejected ;-) , and I can then test it as well.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 22, 2016):

Here it is: PR #459

@X-Ryl669 commented on GitHub (Sep 22, 2016): Here it is: PR #459

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Sep 23, 2016):

Any of you tried the PR yet ?

@X-Ryl669 commented on GitHub (Sep 23, 2016): Any of you tried the PR yet ?

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@BernardGoldberger commented on GitHub (Sep 23, 2016):

Yes, it works for me.

@BernardGoldberger commented on GitHub (Sep 23, 2016): Yes, it works for me.

kerem commented

2026-02-26 02:32:50 +03:00

Author

Owner

@X-Ryl669 commented on GitHub (Nov 28, 2016):

Fixed in the current repository

@X-Ryl669 commented on GitHub (Nov 28, 2016): Fixed in the current repository

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/koel-koel#321

No description provided.

Rows
Columns