Re: [xwiki-users] xwiki issues with Firefox 3
The table/scrollbar missing -problems are related to css. If I use the default css (style.css) everything looks fine. However, when changing the color (e.g style-blue.css) in XWikiPreferences, things get bad. Here are some screenshots when using style-blue.css, comparing FF3 and opera: Space rights: FF3: http://drift.nerdjeje.no/~libak/xwikiscreenshots/spacerights_ff3.png Opera: http://drift.nerdjeje.no/~libak/xwikiscreenshots/spacerights_opera.png Users (added black boxes to remove the names of our users) : FF3: http://drift.nerdjeje.no/~libak/xwikiscreenshots/users_ff3.png Opera: http://drift.nerdjeje.no/~libak/xwikiscreenshots/users_opera.png Bjørnar Bjørnar Libæk wrote: I have seen som problems when using Firefox 3 (beta 5) for linux (Ubuntu), together with xwiki 1.4 (toucan skin): -Tables in e.g. user administration is not showing correctly -When looking at a group page, the scroll bar is missing, so only 15 users are listed -Performance is generally poor. For instance, the top menu bar, and the panels follow the rest of the page when scrolling. This has been verified by a colleague of mine using Firefox 3 RC1, and we see the same performance problems on xwiki.org. Is this something that should be fixed in xwiki, or is it more likely to be a firefox bug? Regards Bjørnar Libæk ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki issues with Firefox 3
The scrolling-performance problem remains after installing the gtk2-engines-murring package. Where is the setting for enabling the cache? It's enabled by default, right? I'm pretty sure I haven't turned it off. Today, I upgraded to FF 3.0 ubuntu release, but no improvements. So, if this Firefox bug is known upstream, I guess it will be fixed soon. Did you find a link to that bug? Bjørnar Squirrel wrote: Gmail behaves better, but other sites not. See for yourself: http://watch.xwiki.org/xwiki/bin/view/Main/ this page is about a different bug: performance issue with absolute position floating elements. Thats known upstream - Alexander -- slow scroll with image as background-repeat https://bugs.launchpad.net/bugs/125970 You received this bug notification because you are a direct subscriber of the bug. On Fri, Jun 6, 2008 at 1:45 PM, Squirrel [EMAIL PROTECTED] wrote: That sudo apt-get install gtk2-engines-murrine helped a lot, although the flickering still remains... On Fri, Jun 6, 2008 at 12:55 PM, Squirrel [EMAIL PROTECTED] wrote: I just installed FF3 again and face the same problem you described. I found this: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/217580 On Fri, Jun 6, 2008 at 12:23 PM, Squirrel [EMAIL PROTECTED] wrote: I had this once too. Could you please check that you have enabled the cache setting in FF3? Also, just for verification reasons, try to untick the 'Allow pages to set their own fonts...' setting under 'Preferences' 'Content' 'Advanced'. On Fri, Jun 6, 2008 at 10:59 AM, Bjørnar Libæk [EMAIL PROTECTED] wrote: I have seen som problems when using Firefox 3 (beta 5) for linux (Ubuntu), together with xwiki 1.4 (toucan skin): -Tables in e.g. user administration is not showing correctly -When looking at a group page, the scroll bar is missing, so only 15 users are listed -Performance is generally poor. For instance, the top menu bar, and the panels follow the rest of the page when scrolling. This has been verified by a colleague of mine using Firefox 3 RC1, and we see the same performance problems on xwiki.org. Is this something that should be fixed in xwiki, or is it more likely to be a firefox bug? Regards Bjørnar Libæk ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki issues with Firefox 3
Guillaume Lerouge wrote: (...) I think that it's due to an issue in the CSS used to switch from the standard Toucan skin to the coloured ones. I'd advise either of those solutions : 1. Least recommended : switch back to the grey skin for now 2. Most recommended : use Firebug and / or other debugging tools to compare the CSS differences between style.css and, say, style-blue.css and try to identify the cause of the issue. Then post a JIRA issue characterizing it so that we can try to solve it :-) I went for solutions 1, as I don't have time to dive into this at the moment. Maybe later.. But can anyone else reproduce this? It's as simple as changing the skin color: goto administration-preferences-skin, and replace style.css with style-blue.css. Save, and go to the administration-users tab (using Firefox 3) and see if the scrollbar is missing (requires more than 15 users) and if the tablewidth has been compressed. Bjørnar ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki issues with Firefox 3
As a lead to anyone wanting to look into this, by eliminating the import statements in style-blue.css, the problems disappear. I did: shell cat style.css css/colors/blue.css style-blue-test.css When selecting style-blue-test.css in the skin object, everything looks fine. I guess this has something to do with how FF3 handles the css imports.. Bjørnar. Guillaume Lerouge wrote: Hi Bjørnar, The table/scrollbar missing -problems are related to css. If I use the default css (style.css) everything looks fine. However, when changing the color (e.g style-blue.css) in XWikiPreferences, things get bad. I think that it's due to an issue in the CSS used to switch from the standard Toucan skin to the coloured ones. I'd advise either of those solutions : 1. Least recommended : switch back to the grey skin for now 2. Most recommended : use Firebug and / or other debugging tools to compare the CSS differences between style.css and, say, style-blue.css and try to identify the cause of the issue. Then post a JIRA issue characterizing it so that we can try to solve it :-) Guillaume ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] xwiki issues with Firefox 3
Ok, I can't let this go..
Using firebug, I compared the css code when 1) the css file is linked
directly from the html , and 2) when imported by another css file, using
the @import statement. The only differences I'm able to spot is that
when style.css is imported from another css file, firefox 3 removes the
css child () and siblings (+) operators, 8 and 1 occurences
respectively. Example:
[case 1 (works)]
html body #xwikieditcontent {
padding:0pt;
}
[/]
[case 2 (fails)]
html body #xwikieditcontent {
padding:0pt;
}
[/]
I can't say if this is the source of the problem, but maybe some of you
xwiki devs can confirm whether it is or not.
I tried to remove all the '' and '+' selector operator from style.css
(direct linking), but that didn't reproduce the misbehavior.. So still
there seems to be some strange things happening during import..
I also tried to create a simple css example to reproduce firefox'
removal of the and + operators, but had no success with that. So the
problem is likely more complex..
Bjørnar
Bjørnar Libæk wrote:
As a lead to anyone wanting to look into this, by eliminating the import
statements in style-blue.css, the problems disappear. I did:
shell cat style.css css/colors/blue.css style-blue-test.css
When selecting style-blue-test.css in the skin object, everything looks
fine. I guess this has something to do with how FF3 handles the css
imports..
Bjørnar.
Guillaume Lerouge wrote:
Hi Bjørnar,
The table/scrollbar missing -problems are related to css. If I use the
default css (style.css) everything looks fine. However, when changing
the color (e.g style-blue.css) in XWikiPreferences, things get bad.
I think that it's due to an issue in the CSS used to switch from the
standard Toucan skin to the coloured ones. I'd advise either of those
solutions :
1. Least recommended : switch back to the grey skin for now
2. Most recommended : use Firebug and / or other debugging tools to
compare the CSS differences between style.css and, say, style-blue.css and
try to identify the cause of the issue. Then post a JIRA issue
characterizing it so that we can try to solve it :-)
Guillaume
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Space rights configuration...
Did you solve this? I got the same problem when upgrading from 1.1 M4 to 1.1.2. When editing global and space rights, the button add access right entry in the GlobalRightsEditorWelcome panel was missing. I found a workaround to this by opening the WebPreferences page for the space a wanted to add access rights to, selecting edit objects, and added a XWiki.XWikiGlobalRights object to the page. Today, when looking closer into this, I found that this misbehaviour has something to do with the $xwiki.rightsmanager.defaultUi variable. This variable tells which gui to use for acces management. By inspecting the code of the GlobalRightsEditorWelcome panel, I found that the button only is showed when the following condition is true: #if ($xwiki.rightsmanager.defaultUi == stable) But for som reason, this variable was undefined, all though I had xwiki.rights.defaultUi = new in xwiki.cfg. What is the relationship between xwiki.rightsmanager.defaultUi and xwiki.rights.defaultUi ? I suspect a typo.. I've never seen the new access right manager in my wiki, so there is obviously something wrong here.. However, by modifying the condition: #if(!($xwiki.rightsmanager.defaultUi) || $xwiki.rightsmanager.defaultUi == stable) everything is back to normal. B Vincent Massol wrote: On Jan 24, 2008, at 7:47 PM, Aleksandar Vidakovic wrote: I had an idea (but don't know if it's stupid ;-) Anyway... could it be that there is a page missing in my space. When I edit the space rights I get this URL: http://localhost:8080/xwiki/bin/admin//WebPreferences?editor=spacerightsglobal=1space= As there is a page WebPreferences in the XWiki space (and this one allows me to edit rights) I would expect the same page in my space . This WebPreferences page is created automatically by the Admin page when you start setting space rights. I've just tried with a vanilla 1.2 release and it worked fine for me so it could be related to your environment somehow. -Vincent Completely wrong? Thanks again for your help... Aleks Aleksandar Vidakovic wrote: No, I don't have this plugin installed. Installed plugins are: - Chatzilla - delicious - gTranslate - Download Statusbar - Firebug - Google Gears - Google Reader Watcher - Googlepedia - Scribefire - Webdeveloper Esbach, Brandon wrote: Sorry, should have made myself clearer. I noticed you were using Firefox, and was just clarifying whether you use the Firefox plugin called NoScript (check this by going to Tools - Add-ons). The rights editor on Xwiki uses Ajax, which is essentially script sent to and from the server. What NoScript does, is it disables certain javascript functionality depending on the address you are browsing, and I've seen it do weird stuff with XWiki in the past. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Documentation?
Vincent Massol wrote: (...) I totally agree with Brandon. I actually gave up looking for the documentation yesterday, thinking that it was probably not moved to the new site yet. I'd like more details on this. What product were you looking documentation for when you gave up? XWiki Enterprice. (...) So far all I'm hearing is that you guys seem to consider XWiki as a single product and not a platform. This is probably the hardest to understand for you if you were coming from the old XWiki.org since this aspect wasn't shown at all. Right on! I was not aware of this change. I wouldn't say it is that hard to understand, though;) Bjørnar ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] rights of current user
Ok, maybe checking permission to WebHome isn't the best way to go, so
if anyone could follow up on the sql query suggestion, it would be nice.
However, I still don't understand why my script doesn't work. If a user
has viewing rights on a WebHome page (the user can actually view the
page), the hasAccessLevel method still returns false. Why is this?? I've
tried replacing 'WebHome' with 'WebPreferences', but with the same result.
Bjørnar
Jan Kodera wrote:
Hi,
i think the problem is, that space preferences is in
${space}.WebPreferences page and not in WebHome. Your script just
find, if the user have rights to WebHome page not for entire space.
WebPreferences has object global
rights and i think there you have to do some sql query to find out, if user
have rights or not.
Jan
On 12/17/07, *Bjørnar Libæk* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I would like to have a script that finds out for which spaces the
current user has view rights. I try to do:
#set($spaces = $xwiki.spaces)
#foreach($space in $spaces)
#set($whome = $xwiki.getDocument(${space}.WebHome))
[$space${space}.WebHome]
#if($whome.hasAccessLevel(view,$xwiki.getUser()))
acess? Yupbr
#else
access? Nopebr
#end
#end
but hasAccessLevel always return false. What am I missing? Is
there any other way to do this?
___
users mailing list
users@xwiki.org mailto:users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] rights of current user
Sergiu Dumitriu wrote: #if($whome.hasAccessLevel(view,$context.getUser())) Ok, I tried this, but now the method returns true every time... Even when explicitly adding an access rule denying view access for a specific user, the method returns true. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
