Hello again,
next issue in FF (may be minor to you, but is annoying to me):
As I have message preview enabled, I have set the number of messages per page to 14, because I want to avoid a vertical scrollbar on the right hand side of the message list.
So I move the horizontal splitter precisely and pixel-exactly to the utmost top position where FF doesn't show a scrollbar.
The problem: After logoff and re-logon the splitter has moved two pixels upwards, which leads to a scrollbar on the right hand side. This is 100% replicable. See screenshot attached.
And I just realized that I even don't need to logoff/logon, I can reproduce the same by simply clicking on "Settings" and then on "Mail" again.
I'm not sure if this an RC or an FF issue. At least it doesn't happen in IE.
But I'd be glad if you could take a look at it.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 29.12.2013 21:09, schrieb Michael Heydekamp:
The problem: After logoff and re-logon the splitter has moved two pixels upwards, which leads to a scrollbar on the right hand side. This is 100% replicable. See screenshot attached.
And I just realized that I even don't need to logoff/logon, I can reproduce the same by simply clicking on "Settings" and then on "Mail" again.
Addendum: Even a simple page refresh with F5 does bring up the issue.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 12/29/2013 09:53 PM, Michael Heydekamp wrote:
Addendum: Even a simple page refresh with F5 does bring up the issue.
I'm unable to reproduce. Firefox 26 on Linux.
Am 30.12.2013 08:18, schrieb A.L.E.C:
On 12/29/2013 09:53 PM, Michael Heydekamp wrote:
Addendum: Even a simple page refresh with F5 does bring up the issue.
I'm unable to reproduce. Firefox 26 on Linux.
See my message with regards to the broken zoom function keys (Linux vs. Win7).
But another interesting observation:
The problem does NOT appear when changing between folders (although this is a sort of page refresh as well)!
Does that tell you something...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 12/30/2013 11:00 PM, Michael Heydekamp wrote:
See my message with regards to the broken zoom function keys (Linux vs. Win7).
Works for me on Windows 7.
But another interesting observation:
The problem does NOT appear when changing between folders (although this is a sort of page refresh as well)!
When you select a folder, the page is not reloaded.
Am 01.01.2014 11:05, schrieb A.L.E.C:
On 12/30/2013 11:00 PM, Michael Heydekamp wrote:
See my message with regards to the broken zoom function keys (Linux vs. Win7).
Works for me on Windows 7.
As you have found, at least the zoom function keys are not a Linux/Win issue. So it will be something different in terms of splitter issues most likely as well.
The strange thing is: FF does this upward move of two pixels just this one time. Once this has happenend, there are no further moves (logically you would think it should do it upon every page refresh).
I'll try it again without any plugins.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 02.01.2014 22:22, schrieb Michael Heydekamp:
Am 01.01.2014 11:05, schrieb A.L.E.C:
Works for me on Windows 7.
As you have found, at least the zoom function keys are not a Linux/Win issue. So it will be something different in terms of splitter issues most likely as well.
The strange thing is: FF does this upward move of two pixels just this one time. Once this has happenend, there are no further moves (logically you would think it should do it upon every page refresh).
I'll try it again without any plugins.
As I said already, this doesn't make any difference, so plugins are not involved.
Then we got the idea that the resolution may be the reason. So I changed the native resolution (1920 × 1080) of my laptop to the next available lower resolution (1280 × 1024). Again, no difference, this upward move of the splitter of two pixels - and as a result the appearance of the annoying scrollbar - did happen again.
This is driving me totally nuts.
Can anybody tell me where I can find the FF cookie where the splitter positions are being saved and read? Probably I can find something there. I'm not that familiar with FF yet, so I'm asking for some advice.
Best regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 03.01.2014 18:47, schrieb Michael Heydekamp:
Am 02.01.2014 22:22, schrieb Michael Heydekamp:
I'll try it again without any plugins.
As I said already, this doesn't make any difference, so plugins are not involved.
Then we got the idea that the resolution may be the reason. So I changed the native resolution (1920 × 1080) of my laptop to the next available lower resolution (1280 × 1024). Again, no difference, this upward move of the splitter of two pixels - and as a result the appearance of the annoying scrollbar - did happen again.
This is driving me totally nuts.
Can anybody tell me where I can find the FF cookie where the splitter positions are being saved and read? Probably I can find something there. I'm not that familiar with FF yet, so I'm asking for some advice.
Ha! I may have found something:
FF doesn't move the splitter two pixels upwards. It does move it to a fixed position instead - whereever it may get this fixed position from. Look:
- I move the splitter significantly downwards (much more than it needs to
be), see "New splitter position.png" attached.
- After a page refresh with F5 the splitter returns to this strange old
position, where the scrollbar does appear. See "Old splitter position after page refresh (F5).png" attached.
So what does that tell us? That the new position that has been set in 1) above is not being saved, right? And that a fixed position is saved somewhere to which FF is always returning to.
That's driving me nuts even more. Any hint...?
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 01/03/2014 07:13 PM, Michael Heydekamp wrote:
That's driving me nuts even more. Any hint...?
Classic skin uses cookies. Larry uses window.localStorage. Could you check with Larry?
Some hints for classic: see lines 8-18 of skins/classic/templates/mail.html. As you can see here, the elements height/position is set by PHP by reading cookie values.
To see cookies in Firefox goto Tools > Web Developer > Web console, choose Network tab, reload the page, select first GET request on the list, select Cookies tab on the right.
Am 03.01.2014 19:29, schrieb A.L.E.C:
On 01/03/2014 07:13 PM, Michael Heydekamp wrote:
That's driving me nuts even more. Any hint...?
Classic skin uses cookies. Larry uses window.localStorage. Could you check with Larry?
Some hints for classic: see lines 8-18 of skins/classic/templates/mail.html. As you can see here, the elements height/position is set by PHP by reading cookie values.
To see cookies in Firefox goto Tools > Web Developer > Web console, choose Network tab, reload the page, select first GET request on the list, select Cookies tab on the right.
Thanks for those hints. I didn't check with Larry yet, although I would prefer that Classic would use use window.localStorage instead of cookies too. Is there a special reason why both skins are doing it different, and are you planning to use window.localStorage for the classic skin in the future as well?
Anyway, we've found an interestingly solution/workaround:
First, we deleted all FF cookies with SQLite Manager. Much to our surprise, that didn't have any effect.
After some playing around, we realized the following: Invoking Roundcube on our server with...
a) http://www.webmail.freexp.de: Splitter settings were neither being saved nor respected. Always the same odd default values did apply.
b) http://webmail.freexp.de: Splitter settings were being saved as well as being respected.
For IE, that doesn't make a difference apparently. For FF, it does. So we'll be solving this on our server.
Nonetheless it's still unclear where FF got those odd default values (where the splitter positions have always been reset to) from, when being invoked with the "www." prefix. Probably some ancient IE cookies, and due to the slightly different rendering of both engines, it made this annoying scrollbar appear in FF...?
Anyway, not a Roundcube issue apparently. But feel free to comment, though. At least we were quite surprised of the above.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
-
A.L.E.C -
Michael Heydekamp