When one asks konqueror to use larger/smaller fonts (e.g., using the toolbar buttons with mag. glass and +/-), the window of the HTML document currently viewed jumps elsewhere. E.g., try http://lib.ru/LINUXGUIDE/torvalds_jast_for_fun.txt (that's the Russian translation of the "Just for fun" book by Linus) - scroll it to approx. 80% using the scrollbar and then click the mag glass to enlarge the font - several times.
Hi, We (the Debian Qt/KDE team) are trying to update the bug status of some old bugs in the BTS. You filed the bug #252620 "konqueror: resizing browser font repositions the current window in the document" some time ago, you can read the bug report at: http://bugs.debian.org/252620 We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs in the past years than the maintainers could handle. We are trying to fix this now, but we need your help. So please respond to this mail and tell us if: - you are still experiencing this bug (adding in what version) - the bug was already fixed, - or if you have extra information on how reproduce this bug.--- Thanks in advance, Ana Guerrero, on behalf of the Debian Qt/KDE team
Hi, We (the Debian Qt/KDE team) are trying to update the bug status of some old bugs in the BTS. You filed the bug #252620 "konqueror: resizing browser font repositions the current window in the document" some time ago, you can read the bug report at: http://bugs.debian.org/252620 We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs in the past years than the maintainers could handle. We are trying to fix this now, but we need your help. So please respond to this mail and tell us if: - you are still experiencing this bug (adding in what version) - the bug was already fixed, - or if you have extra information on how reproduce this bug.--- Thanks in advance, Ana Guerrero, on behalf of the Debian Qt/KDE team
Sure, I understand your concerns. I'm not complaining at all, actually, I feel a bit uncomfortable myself having not debugged it further to the point of a suggested patch given the bug age. Anyway, I've retested it (according to the very reproduction example there in the original report), and it still happens, see the Version: field. HTH, V
Hi! I have tested it a bit also - and it somehow seems that it is maybe on 'screen 20' counted from top - and after enlarging the font it moves to 'screen 20' again. As the font size have changed, it is of course a 'jump' to relocate to new 'screen 20' I don't know wether it is desired behaviour or not. /Sune
Hi! I have tested it a bit also - and it somehow seems that it is maybe on 'screen 20' counted from top - and after enlarging the font it moves to 'screen 20' again. As the font size have changed, it is of course a 'jump' to relocate to new 'screen 20' I don't know wether it is desired behaviour or not. /Sune
Looks like you are right. I would think that a much more sensible behaviour would be to just focus on the same rendered DOM objects as were in the focus before the font size change. Obviously, the zoom level means that some of them would need to go out of the viewable area anyway in case of enlarging the font, so there is some freedom here -- should the top element stay at the top? or the center one at the center? In sequential browsing the 1st one probably makes more sense. Zooming back out should definitely have ALL the elements from the main flow that were on the screen remaining there, with an addition of new stuff that gets packed in.