Forum OpenACS Q&A: Xowiki page doesn't show in MSIE

Collapse
Posted by Aernout Schmidt on
Just recently I noticed that my xowiki pages only show in MSIE after the (previously invisible) text has been selected in the browser. What am I doing wrong? (Firefox is behaving nicely).
Collapse
Posted by Gustaf Neumann on
Are you using a customized view.adp file? there was some time ago a problem with in a customized view.adp on oacs.org, which was due to ab unclosed script tag. This is fixed since a few weeks. Can you give an example?
Collapse
Posted by Aernout Schmidt on
I think I have modifies something to get over the problem of printing the wiki commands too high on the page. This is (I think) the relevant parts of view.adp I use:

FOR THE LOCATION OF THE COMMANDS(SEEMS TO WORK):

#wikicmds {position: relative;top: -14px;  right: 0px; height: 0px;
      text-align: right;  font-family: sans-serif; font-size: 85%;color: #7A7A78;}
#wikicmds a, #wikicmds a:visited { color: #7A7A78; text-decoration: none;}
#wikicmds a:hover {text-decoration: underline;}
#wikicmds a:active {color: rgb(255,153,51);}

LAST PART OF VIEW.ADP - MAGHT BE RELEVANT?

  <!-- The following DIV is needed for overlib to function! -->
  <div id="overDiv" style="position:absolute; visibility:hidden; z-index:1000;"></div>

<div id='wikicmds'>
  <if @write_p@ eq 1>
    <a href='@edit_link@' accesskey='e' title='Diese Seite bearbeiten ..'>Edit</a> &middot;
    <a href="@rev_link@" accesskey='r' >Revisions</a> &middot;
<!--  <a href="changes?object_type=CrWikiPage&item_id=@item_id@" accesskey='c'> chg</a> &middot; -->
  <a href="@new_link@" accesskey='n'>New Page</a> &middot;
  <a href="@delete_link@" accesskey='d'>Delete</a> &middot;
  </if>
  <a href="@index_link@" accesskey='i'>Index</a>
</div>

@content;noquote@
<div style="clear: both; text-align: left; font-size: 85%;">
<p/>&nbsp;<hr>References to this Page: @references;noquote@
@lang_links;noquote@</div><br>
<if @gc_comments@ not nil>
  <p>Add comment
  <ul>@gc_comments;noquote@</ul></p>
</if>
<if @gc_link@ not nil>
  <p>@gc_link;noquote@</p>
</if>

Collapse
Posted by Gustaf Neumann on
Concerning positioning of the command bar: the positioning depends whether one is using dotlrn or not. the current setting is for dotlrn, i will try to make it more intelligent.

About visibility in IE: i can't spot anything wrong. Normally, i don't use IE, but i checked all my test cases and it worked nicely...

Can you make a page with problems in IE public accessible, such i can get the full picture?

Collapse
Posted by Aernout Schmidt on
Gustaf Neuman solveed the problem. I quote part of his message:

Aernout,
this is indeed strange. the DIV id="page-body" does not display in IE.
Try changing

#page-body {background: #fff; font: 10pt Arial, Helvetica, sans-serif;}

to

#page-body {background: "#fff"; font: 10pt Arial, Helvetica, sans-serif;}

in xowiki/www/view.adp
Can you please confirm this, whether this
helps in general? Strangely enough, i see no requirement that hexcolors
must be quoted.... maybe an IE bug?

And indeed, this helped!

Thanks Gustaf

Collapse
Posted by David Ghost on
I have just installed the latest OACS 5.3.2
and I come across the same trouble.
But this time I can't find the related source files like view.adp....what should I do?
Collapse
Posted by Gustaf Neumann on
The default adp file is named since a while view-default.adp, the style information went out into xowiki.css. The version in cvs head does not set the background color, the version in oacs-5-3 uses
div.xowiki-content {background: #fff; font: 10pt Verdana, Arial, Helvetica, sans-serif;}
Most likely, you can remove the background color setting.

The strange thing is that we use xowiki with these setting on a system with more than 30.000 users, nearly the half of it is using IE, but we don't see the problem.

Please report back, if changing the color helps in your setup as well, and if not, please provide more information about the versions of IE and the version of xowiki you have installed.

Collapse
Posted by David Ghost on
Thanks Gustaf,
It's been addressed!