Penultimate line: s/error/arrow.

Sorry :(

Just confirming I saw that the details screen keeps showing the package it installed when switching to that screen, instead of continuing to show the packages that are installed.

Also confirming that scrolling up and down doesn't improve this.

(Seen in a 32 bits and in a 64 bits install from the 5alpha2 dual iso)

CC: (none) => marja11

Hello,
It goes from bad to worse.
I tried a net - install today:
The radio buttons and the checkboxes do not show any more their state.

Impossible to make an installation.

It could come from the last update of gtk3.
Since the use of gtk3, I see only problems with the installer, often small, it is true.
But now I am blocked in the tests of cauldron.

I wonder if it would not be more sensible to make the installer under qt, rather than under gtk3 !

CC: (none) => paiiou

(In reply to Georges Eckenschwiller from comment #3)
> Hello,
> It goes from bad to worse.
> I tried a net - install today:
> The radio buttons and the checkboxes do not show any more their state.
> 
> Impossible to make an installation.

Please, one problem per bug - this one is about the scrollbar.

CC: (none) => doktor5000

(In reply to Florian Hubold from comment #4)
> Please, one problem per bug - this one is about the scrollbar.

I completely agree, but I think that the origin is the same: gtk3

(In reply to Georges Eckenschwiller from comment #5)
> (In reply to Florian Hubold from comment #4)
> > Please, one problem per bug - this one is about the scrollbar.
> 
> I completely agree, but I think that the origin is the same: gtk3

or not since released alpha2 was not affected (without update) 
https://bugs.mageia.org/show_bug.cgi?id=13929

Hi,
I can make a mistake, but it has been several months since I notice small problems.

Even there I can make a mistake, but I am almost sure that it is since the passage of the installer from gtk2 to gtk3.

I shall make another two remarks to support my suspicions:
- The developers of Xfce hesitate to migrate to gtk3
- The developers of LXDE preferred to migrate to Qt rather than gtk3.

Still unable to see the tail of the package list continuously.

Observed in beta1 build dtd 23/10 of 64 bits iso.

Whiteboard: 5alpha2 => 5beta1
Source RPM: drakx-installer-stage2-16.38-1.mga5 => drakx-installer-stage2-16.44-1.mga5

build no. 3 of beta1:

There is a little response from the cursor, but at this point with hardware that is equipped with touchpad only, the cursor does not even show above the scrollbar. With the cursor being moved from beyond the right hand edge of the upper GUI towards the package installation details screen, the cursor turns into a non-pointer, i.e. like a capital letter i, but larger and thinner.

Once the user switches to the terminal screens and back, the issue is resolved for a while, and I managed to scroll the package list to the end of the tail once.

But leaving it by itself (perhaps touching the mouse from the side every now and then) the way it should work is lost again well before the rpm transactions finish.

Perhaps caused by gtk*

Assignee: bugsquad => thierry.vignaud

Same with 5beta2 build 1

Source RPM: drakx-installer-stage2-16.45-2.mga5 => drakx-installer-stage2-16.47-1.mga5
Whiteboard: 5beta1 => 5beta2

pre-5beta2 2nd build, dual iso

It is less bad than it was, I could see the tail - or close to the tail - for a while, and scroll back to the tail when it got behind too much.

However, towards the end of packages install the window was frozen at about 2/3rd of the list and it was impossible to scroll at all.

same in Mga5b2 i586 dvd

CC: (none) => westel

This feature worked perfectly in earlier product versions of Mageia, giving confidence in the installer, but for some reason has been infuriatingly like this from the beginning of Mageia-5.

Please, can this ugly glitch in the installer be fixed soon?
  I hate to think of the effect on the confidence in the installer of newcomers to Mageia if it remains...

CC: (none) => maurice

So we do have multiple issues in this bug, which I also reported in Bug 14968.

When installing packages, if you click Details, you'll notice some UI issues.

First, the text window doesn't continue to scroll down as text is written to the bottom of it, showing the packages that are being installed.  It'll follow down for a few packages, then it'll get and stay stuck where it is.  You can manually scroll it to the bottom, and then it'll do the same: follow for a few and then get stuck.

Second, the scroll bar is strange and doesn't work properly, as it doesn't do the correct thing when you click on various parts of it.

Finally, the UI is completely non-responsive while packages are downloading.  It is only functional while packages are actually installing/uninstalling on the system.

CC: (none) => ennael1, luigiwalser

*** Bug 14968 has been marked as a duplicate of this bug. ***

The textarea does not refresh properly, I mean the scroll never gets updated to show current package. This is on Mageia 5 Beta 2.

CC: (none) => linuxero

Still valid.

Whiteboard: 5beta2 => 5beta3

Valid beta 3 round 3 (feb 9th)

valid rc first round (dual on 32 and on 64 bit hw), DrakX v16.62

Whiteboard: 5beta3 => 5rc

*** Bug 15412 has been marked as a duplicate of this bug. ***

CC: (none) => vzawalin1

Still valid in Classical i586 DVD kde install RC candidate.

CC: (none) => andrewsfarm

(In reply to David Walser from comment #15)
> First, the text window doesn't continue to scroll down as text is written to
> the bottom of it, showing the packages that are being installed.  It'll
> follow down for a few packages, then it'll get and stay stuck where it is. 
> You can manually scroll it to the bottom, and then it'll do the same: follow
> for a few and then get stuck.

That's indeed a regression.
 
> Second, the scroll bar is strange and doesn't work properly, as it doesn't
> do the correct thing when you click on various parts of it.

That would be a gtk+ bug.

> Finally, the UI is completely non-responsive while packages are downloading.
> It is only functional while packages are actually installing/uninstalling on
> the system.

we're not multi-threaded, we can only answer to events when rpmlib fires a call to a callback

(In reply to Thierry Vignaud from comment #23)
> > Second, the scroll bar is strange and doesn't work properly, as it doesn't
> > do the correct thing when you click on various parts of it.
> 
> That would be a gtk+ bug.

Yeah, I thought I had heard that gtk+3 scrollbars worked incorrectly by default.  Isn't there a setting that it supports that fixes that?  Is there a way for the installer to use a gtk settings file?

> > Finally, the UI is completely non-responsive while packages are downloading.
> > It is only functional while packages are actually installing/uninstalling on
> > the system.
> 
> we're not multi-threaded, we can only answer to events when rpmlib fires a
> call to a callback

OK, so that's a separate issue.  It'd be ideal to fix it, but probably a lot more difficult.

Some relevant documentation for this issue: https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.html

"The position of the scrollbars is controlled by the scroll adjustments. See GtkAdjustment for the fields in an adjustment - for GtkScrollbar, used by GtkScrolledWindow, the âvalueâ field represents the position of the scrollbar, which must be between the âlowerâ field and âupper - page_size.â The âpage_sizeâ field represents the size of the visible scrollable area."

CC: (none) => remi

It might help to have a little mockup perl-Gtk3 program that contains such a window set up the same as the installer does that has something running that continuously prints something into it, so we could experiment easily with it locally.

*** Bug 15475 has been marked as a duplicate of this bug. ***

CC: (none) => unruh

Rephrasing the problem: Current status (RC) seems to be that the details window is correctly accumulating lists of packages installed, scroll bar on right is correctly getting proportionately shorter and drifting up in the scroll space as packages accumulate, but focus is not staying on the last line.  For me, can drag the scroll bar up and down normally and see all that is there - just need the focus to stay on the last line.

CC: (none) => tablackwell

Agreed. That is what I see as the problem as well. I was on Beta 3 (have no idea how to get the RC as only the beta 3 seems to be anywhere I look). Note that I have never seen it stick at the bottom. It is always static no matter where you place the scrollbar, showing old installed packages, not the currently being installed packages.

Currently, builds of the RC are not available to the general public. Only the developers and the QA team testers have access.

I noticed that if you toggle back and forth between "Details" and "No Details," when you first get to "Details" the focus is where it should be, and stays there for two packages before it stops. Toggling again repeats that.

To Thomas and w unruh: builds of the RC are not available, but packages on the mirrors are. This means that you could try do to a network install (using boot.iso). It can fail if the mirror changes during the installation, but it would be enough to check the latest fixes.

CC: (none) => stormi

Adding the 5alpha2 marker (comment 1 refers to this release) for bisecting purpose. I'll try 5alpha1 to see if the bug was present or introduced in between.

Whiteboard: 5rc => 5alpha2 5rc

I confirm that there was no bug on 5alpha1, at least in the dual DVD.
Looking at the drakx log, there weren't any changes around that time that could explain the regression IMO: http://gitweb.mageia.org/software/drakx/log/?ofs=250

So the issue probably originates from a GTK+ update in Cauldron at that time, I'll have to check if I can find logs of the packages pushed on the buildsystem.

(In reply to Rémi Verschelde from comment #33)
> So the issue probably originates from a GTK+ update in Cauldron at that
> time, I'll have to check if I can find logs of the packages pushed on the
> buildsystem.

mgarepo rpmlog gtk+3.0, mgarepo rpmlog drakx-installer-stage2

Correlating the dates should allow you to nail down the gtk+3.0 versions used in the installer at various stages.

Indeed, thanks for the tip.

5alpha1 was released on July 8th, which corresponds to:
- drakx-installer-stage2-16.37-1.mga5: http://gitweb.mageia.org/software/drakx/commit/?id=1fca8cbb80aa09622e7bb385a837063b7d5a57b9
- gtk+3.0-3.13.3-4.mga5 (rev 641613)

5alpha2 was released on August 13th with:
- drakx-installer-stage2-16.38-2.mga5: http://gitweb.mageia.org/software/drakx/commit/?id=caa29bb632d10bf29eada0a5c963ca910af59f0d
(nothing relevant between the two commits)
- gtk+3.0-3.13.6-1.mga5 (rev 662002), drakx-installer-stage2 was effectively rebuilt against this version


Now to investigate what changed between gtk+3.0 3.13.3 and 3.13.6, including our patches. For reference, the changelog is:

* Tue Aug 12 2014 ovitters <ovitters> 3.13.6-1.mga5
+ Revision: 662002
- new version 3.13.6

* Tue Jul 22 2014 ovitters <ovitters> 3.13.5-1.mga5
+ Revision: 655442
- new version 3.13.5
- make use of apply_patches

* Sun Jul 20 2014 colin <colin> 3.13.4-3.mga5
+ Revision: 654828
- Fix immodules rpm filetrigger filter regex

* Sun Jul 20 2014 colin <colin> 3.13.4-2.mga5
+ Revision: 654749
- Make immodule updating binary layout match gtk+2.0 package
- Move gtk-query-immodules into an RPM filetrigger.

* Sun Jul 20 2014 colin <colin> 3.13.4-1.mga5
+ Revision: 654733
- Move the gtk-query-immodules to the lib package where it's needed
- New version: 3.13.4
- Remove upstream patches
- Package Adwaita stubs and conflict with gnome-themes-standard ofter move to gtk+

* Mon Jun 30 2014 tmb <tmb> 3.13.3-4.mga5
+ Revision: 641613
- gtkcellrendereraccel: Use a GtkInvisible to grab on (mga#13536)

For the changes list between 3.13.3 & 3.13.6, see: https://git.gnome.org/browse/gtk+/plain/NEWS?h=gtk-3-14

Olav, this looks like a gtk+3.0 regression

CC: (none) => olav
Source RPM: drakx-installer-stage2-16.47-1.mga5 => drakx-installer-stage2-16.47-1.mga5, gtk+3.0

GTK+ release notes between 3.13.3 and 3.13.6:
- 3.13.4: https://mail.gnome.org/archives/ftp-release-list/2014-July/msg00029.html
- 3.13.5: https://mail.gnome.org/archives/ftp-release-list/2014-July/msg00069.html
- 3.13.6: https://mail.gnome.org/archives/ftp-release-list/2014-August/msg00009.html

There are mentions to GtkScrolledWindow, so that might be worth looking into.

Ah Thierry's link is even better.

I've had a look at the complete commit changelog between 3.13.3 and 3.13.6, looking for the "scroll" keyword.

Here are some relevant findings:
- GtkScrolledWindow: Animate the scroll-child keybinding
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=939fbc43e10b60dfb0406cf317d3266ff2f41e02
- GtkScrolledWindow: Enable animated scrolling
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=3dcd0a24b1871c71e667df180334b4b861fbbc52
- scrolledwindow: Remove overshoot window and displacement animation
  https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-14&id=7bdc219464f786ef067554bb7c059f84ccbdacb8

Quoting the second commit log:
  We use gtk_adjustment_enable_animation to enable animated
  updates of the adjustments. Currently, this is enabled
  unconditionally, and with a duration that is hardcoded.


Would that be our issue? Maybe we don't support those animations, or don't use them properly, but since GTK+ devs helpfully force-enabled this new feature, it might have broken our setup.

We could try to set gtk_scrolled_window_should_animate to false.

You can unpack the installer and use drakx-in-chroot in order to test different versions of libgtk+:
See https://wiki.mageia.org/en/Drakx-installer_tips_and_tricks#drakx-in-chroot

Basically you need either a local mirror or urpm-proxy or a minimal mirror.
In the later case, you need to mirror at least the following files (from eg ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/):

install/stage2/VERSION
install/stage2/mdkinst.sqfs
product.id
VERSION
misc/mdkinst_stage2_tool
misc/drakx-in-chroot 

then you can run the following commands:

misc/mdkinst_stage2_tool --uncompress install/stage2
# or unsquashfs -dest install/stage2/live install/stage2/mdkinst.sqfs
# if you don't want to mirror misc/mdkinst_stage2_tool
./misc/drakx-in-chroot $PWD ~/tmp/test-chroot

For faster tests, I advocate using (for eg: french):

./misc/drakx-in-chroot $PWD ~/tmp/test-chroot --useless_thing_accepted --flang fr --keyboard fr --tune-rpm
 
(so that it skips license/lang/keyboard steps as well as sync() calls from rpmlib)


If you don't have a local mirror and are trying the above minimal mirror, you would need to add the  --repository=$URI option. eg:

./misc/drakx-in-chroot $PWD ~/tmp/test-chroot --useless_thing_accepted --flang fr --keyboard fr --tune-rpm --repository=ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/

You can rebuild gtk+3.0 from other versions and overwrite the /usr/lib64/libgdk-3.so.0* in install/stage2/live/lib64/ with the one from your new lib64gtk+3_0 package.

Once you bisected the last good version of gtk+3.0 & the first broken version, we would know where to look for regressions

(In reply to Thierry Vignaud from comment #40)
> If you don't have a local mirror and are trying the above minimal mirror,
> you would need to add the  --repository=$URI option. eg:
> 
> ./misc/drakx-in-chroot $PWD ~/tmp/test-chroot --useless_thing_accepted
> --flang fr --keyboard fr --tune-rpm
> --repository=ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/
> cauldron/x86_64/

$ misc/drakx-in-chroot $PWD ~/tmp/test-chroot --useless_thing_accepted --flang en --keyboard en --tune-rpm --repository=http://proxy.example.net/pub/linux/mageia/distrib/cauldron/i586/
[sudo] password for student:
mount: special device http://proxy.example.net/pub/linux/mageia/distrib/cauldron/i586/ does not exist
running "sudo mount http://proxy.example.net/pub/linux/mageia/distrib/cauldron/i586/ /tmp/drakx-in-chroot/tmp/media -o bind" failed: 8192
umount: /tmp/drakx-in-chroot/tmp/media: not mounted

proxy.example.net is fudged, but I used the hostname of our local mirror.

There seems to be inconsistent usage of $repository and $repository_uri in the script.

This patch fixes the issue for me:

--- mdkinst/lib/libDrakX/install/steps_gtk.pm.orig	2015-03-18 23:17:17.587656103 +0000
+++ mdkinst/lib/libDrakX/install/steps_gtk.pm	2015-03-18 23:17:28.475582871 +0000
@@ -643,6 +643,7 @@
 	    gtkval_modify(\$pkg_progress, 0);
 	    my $p = $packages->{depslist}[$id];
 	    mygtk3::gtkadd($pkg_log_widget, text => sprintf("\n%s: %s", $p->name, translate($p->summary)));
+	    $pkg_log_widget->{to_bottom}->('force');
 	    $current_total_size += $last_size;
 	    $last_size = $p->size;
 
It is of course a workaround, not a fix for gtk. It does mean that you can't stop the text scrolling (i.e. it always jumps back to the bottom when a new line is printed) - but that is probably preferable to the current behaviour.

CC: (none) => mageia

Martin,

 " It does mean that you can't stop the text scrolling (i.e. it always jumps back to the bottom when a new line is printed) - but that is probably preferable to the current behaviour."

this is part of the behaviour that has been missing.
If it also allows  control by the user to move up to see packages that have already been installed but have moved out of the top of the details window, this would be great.

(In reply to ben mcmonagle from comment #44)
> this is part of the behaviour that has been missing.
> If it also allows  control by the user to move up to see packages that have
> already been installed but have moved out of the top of the details window,
> this would be great.

You can scroll up, but as soon as you stop moving the scroll bar, the next line of output will force it back to the bottom.

Having said this, my (maybe faulty) recollection is that older versions of the installer behaved like this too.

Maybe we should have a look at how gnome-terminal solves the problem - it has an option to turn this behaviour on and off.

patch added in drakx-installer-stage2-16.68-2.mga5. Not integrated directly in drakx as I'd like tv to check it also. At least we will be able to test it in next round of isos

confirmed, it's fixed in netinstall

commit 8f16c5d8220e5d9b7bb2e5439061752eea348d76
Author: Thomas Backlund <tmb@...>
Date:   Fri Mar 20 22:30:36 2015 +0159

    - work around scrollbar issues during package install
      (Martin Whitaker, mga#13894)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=8f16c5d8220e5d9b7bb2e5439061752eea348d76

(In reply to Rémi Verschelde from comment #39)
> Quoting the second commit log:
>   We use gtk_adjustment_enable_animation to enable animated
>   updates of the adjustments. Currently, this is enabled
>   unconditionally, and with a duration that is hardcoded.
> 
> 
> Would that be our issue? Maybe we don't support those animations, or don't
> use them properly, but since GTK+ devs helpfully force-enabled this new
> feature, it might have broken our setup.
> 
Yes, this is indeed the culprit. The subroutine _allow_scroll_TextView_to_bottom in libDrakX/mygtk3.pm tests whether the vertical scrollbar is currently at the bottom end of its range each time a new line is printed, and only scrolls down further if it is. With animated (i.e smooth) scrolling, the scrollbar may not yet have reached its final position when the next line is printed, defeating this test.

An alternative fix for this bug is:

--- mdkinst/lib/libDrakX/mygtk3.pm.orig	2015-03-18 21:55:13.752999986 +0000
+++ mdkinst/lib/libDrakX/mygtk3.pm	2015-03-21 00:23:41.605360607 +0000
@@ -1478,7 +1478,8 @@
     sub {
 	my ($o_force) = @_;
 	my $adjustment = $scrolledWindow->get_vadjustment;
-	if ($o_force || $adjustment->get_property("page_size") + $adjustment->get_value == $adjustment->get_property("upper")) {
+	my $margin = 40; # allow for lag due to animated scrolling
+	if ($o_force || $adjustment->get_page_size + $adjustment->get_value + $margin >= $adjustment->get_upper) {
 	    flush(); 
 	    $textView->scroll_to_mark($textView->get_buffer->get_mark('end'), 0, 1, 0, 1);
 	}

The value of 40 is empirical, and might need increasing to work reliably on all machines.

This alternative fix allows the user to scroll back through the log without it automatically jumping back when a new line is printed.

N.B. my previous patch should be reverted if this is applied.

Thanks for this new patch Martin, I did some tests using drakx-in-chroot:
- with a fast distant mirror, it works well, the scrollbar stays at the bottom and the latest lines are always displayed
- with a slow distant mirror (distrib-coffee), I often experience a small offset with something like two or three lines off-screen. I've noticed that I can improve this by moving the flush(); call _before_ the if, so that the calculations are done on what will actually be displayed.


Now, in both cases, with and without moving the flush(); call, it seems that the logic which would make it possible to browse back in the history (and thus stop automatically jumping to the bottom) is not working. I can use the scrollbar to move in the history (when packaged are not being downloaded, that is, since the installer is not multithreaded), but then it jumps back to the end when a new package is installed.

I think that was already the case before the Gtk+ regressions though, but since you seem to explain that there is indeed a logic that should make it possible to browse in the history and to leave the scrolling be in such cases, then there might still be something off.

(In reply to Rémi Verschelde from comment #50)
> Now, in both cases, with and without moving the flush(); call, it seems that
> the logic which would make it possible to browse back in the history (and
> thus stop automatically jumping to the bottom) is not working. I can use the
> scrollbar to move in the history (when packaged are not being downloaded,
> that is, since the installer is not multithreaded), but then it jumps back
> to the end when a new package is installed.
> 
> I think that was already the case before the Gtk+ regressions though, but
> since you seem to explain that there is indeed a logic that should make it
> possible to browse in the history and to leave the scrolling be in such
> cases, then there might still be something off.

It works for me when I do a normal install from a USB stick. I've tried to reproduce your results using drakx-in-chroot, but I get the same error that David reported in comment 41.

FYI, I'm running drakx-in-chroot with:

/usr/lib64/drakx-installer-stage2/misc/drakx-in-chroot http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/cauldron/x86_64/ /home/akien/tmp/test-chroot --keyboard fr

Doesn't that mean you're using the stage2 from the remote repository? If I follow your example, I see the behaviour you do. But if I patch drakx-in-chroot to use my local mdkinst.sqfs, it behaves properly.

(In reply to Martin Whitaker from comment #53)
> Doesn't that mean you're using the stage2 from the remote repository? If I
> follow your example, I see the behaviour you do. But if I patch
> drakx-in-chroot to use my local mdkinst.sqfs, it behaves properly.

Yes you are right, I'm not really experienced with drakx-in-chroot usage yet :-)
Let's push the patch live since you've confirmed that it's working locally.

commit ff785ad67f69650b978704b7d2043389e0067222
Author: Rémi Verschelde <remi@...>
Date:   Sat Mar 21 09:46:47 2015 +0100

    better fix for the scrollbar in the package installation details window
    
    patch by Martin Whitaker (mga#13894)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=ff785ad67f69650b978704b7d2043389e0067222

Don't forget you need to revert the previous patch as well.

(In reply to Martin Whitaker from comment #56)
> Don't forget you need to revert the previous patch as well.

Yes I've done it too but forgot to mention the bug report in the commit log: http://gitweb.mageia.org/software/drakx/log/?id=16.70

I am happy to confirm that this bug does not occur with the 23/3/2015 classic iso for 64-bit Mageia-5RC.

Well done, Martin et al!

Confirmed in the 23/3/2015 i586 DVD as well. It works as described in Comment #50, a vast improvement.

I've submitted a bug report against gtk to see if we can get a more robust fix for this in Mageia 6:

  https://bugzilla.gnome.org/show_bug.cgi?id=746773

commit 7689ff61dca492a808d1793cfadea025ecad9cf4
Author: Rémi Verschelde <remi@...>
Date:   Mon Mar 30 09:27:08 2015 +0200

    Revert "Revert "work around scrollbar issues during package install""
    
    This reverts commit b79658e0019ed214bd3ca27705a373895c67e16b.
    
    As stated in 04cfaf0, the second patch for mga#13894 was not doing the job
    perfectly so we revert to the first patch.
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=7689ff61dca492a808d1793cfadea025ecad9cf4

I have developed a more robust fix for this, based on patching GTK to add a property to the scrolled window widget that allows animation to be disabled (just for that widget). But I guess it's a bit late to get into Mageia 5.

(In reply to Martin Whitaker from comment #62)
> I have developed a more robust fix for this, based on patching GTK to add a
> property to the scrolled window widget that allows animation to be disabled
> (just for that widget). But I guess it's a bit late to get into Mageia 5.

That sounds great! I guess it's safer to wait for Mageia 6 yes, now that we have at least a patch that addresses the main issue (the scrollbar not automatically scrolling down).

I'll downgrade the priority and add this one to the Mageia 6 tracker (i.e. RESOLVED FIXED for Mageia 5).

Priority: release_blocker => Normal
Blocks: (none) => 15527
Whiteboard: 5alpha2 5rc => 5alpha2 5beta3

(In reply to Rémi Verschelde from comment #63)

> 
> I'll downgrade the priority and add this one to the Mageia 6 tracker (i.e.
> RESOLVED FIXED for Mageia 5).

Maybe clone it for Mageia 6, so this one can really be closed?

> Maybe clone it for Mageia 6, so this one can really be closed?

I don't think it worth the gain, most of the relevant information is in this bug report.

*** Bug 15753 has been marked as a duplicate of this bug. ***

CC: (none) => lsdm

(In reply to Martin Whitaker from comment #62)
> I have developed a more robust fix for this, based on patching GTK to add a
> property to the scrolled window widget that allows animation to be disabled
> (just for that widget). But I guess it's a bit late to get into Mageia 5.

Maybe you should attach your patch to this bug report?

Target Milestone: --- => Mageia 6
Whiteboard: 5alpha2 5beta3 => FOR_ERRATA

I would not put this in the errata as the current state of this bug is "the scrollbar works as it always did". IMO we should not clutter errata with cosmetic issues, people reading the errata need to know what's really important and might lead to installation difficulties or explain the problem they met.

This bug will probably have its place in the Mageia 6 release notes when we have improved the behaviour of the scrollbar compared to early Mageia or Mandriva times.

Whiteboard: FOR_ERRATA => (none)

Ok, agreed.

IMHO this is solved with current 6sta1, hence closing it.
Reopen in case of disagreement.

Status: NEW => RESOLVED
Resolution: (none) => FIXED