Protein Explorer's Implementation
Microsoft's Internet Explorer
First included in PE 1.91.
Revised/added in PE 1.92: window size,
Added in PE 1.93: Embed commands follow script file
Added in PE 1.98: Link to How and Why PE Works Better in Netscape than IE.
This is a technical document about PE's construction -- you do not need
to read it to use PE! It is provided for those who may be interested in
Abbreviations used in this document:
IE Microsoft's Internet Explorer browser;
IMBIF Immediate-Mode Button in Invisible Frame.
NS Netscape's browser;
PE Protein Explorer;
For background and an introduction to the PE in IE project, and
for details on the implementation of
browser and Chime version testing, please see Browser Testing first.
I have made a very large effort to make PE work in IE as well as possible,
within the limitations of Chime's function in IE. There are some inadequacies
that are beyond my control. These are listed in
How and Why PE works better in
Netscape 4.7x/4.8x than in IE.
In order to get PE to run in IE, first the idiosyncracies and bugs
for Chime+IE needed to be discovered and understood, and then worked
as a volunteer. Below are a list of these issues and the strategies
used to work around them.
Major/Critical Issues Fixed.
- Browser and Chime version detection were completely
redesigned, as explained
function, defined by the invocation of Chime, executeScript().
This uses a proprietary Netscape mechanism called LiveConnect.
In early versions of Netscape, use of the IMBIF method (read on)
caused the browser to crash frequently, which forced me to begin using
LiveConnect. PE continues to use LiveConnect (for NS only) since there has been
no need to change (see s2netscape() in shared/s2c2.js).
LiveConnect is not implemented in IE. Therefore, command script
strings are sent to Chime by using JS to re-write a document contained in an
invisible iframe. The document contains a single "immediate-mode" button
that executes without being clicked.
This method is called IMBIF (see abbreviation
list above). IMBIF has been for several years
demonstrated in a downloadable interface. For the implementation in PE,
see the IFRAME created in the Chime frame in protexpl/pe_proj.htm,
and IMBIF() in shared/s2c2.js.
When Chime 2.6 SP4 was released (Sept 12, 2002), a change
was needed in the IFRAME (first reported by Paul Pillot on the
list on Sept 13). Previously,
the IFRAME could be made invisible by having a height and width of zero pixels.
With SP4, this failed to send commands to Chime in IE. The IFRAME
needed to be >5 pixels in each dimension. In PE, it was made invisible
with "frameborder=0" (see IFRAME in protexpl/pe_proj.htm)
and by keeping the background color of the series of contained
documents the same as that of the surrounding background.
- Single quotes prohibited in commands.
IMBIF requires that that command script string be quoted. I used
single quotes (') so anything that needed to be quoted in the
command script could use double quotes ("), because I thought people
would be more likely to use double quotes. Single quotes cannot be
used in commands sent to Chime because they prematurely end the
command string. (I tried every escape mechanism I could think of without
success, but I may have missed a trick. I tried \' and \\'.)
If you manually enter a command containing
single quotes, an error message
will intercept to prevent malfunctions.
Single quotes were removed from all script strings
(e.g. in comments) (I hope).
- Semicolons in comments in script strings caused no
problem in NS, but were interpreted as an end-of-command in IE, thereby
typically causing the remainder of the comment to be misinterpreted
as an invalid command. Semicolons were removed from all script strings
- Message unscrambling.
PE needs to parse the message stream returning from Chime in
order to determine many crucial pieces of information, such as
the selected atom count, and when Chime has completed a script
and PE can go from Busy to Ready. All this requires that messages
come back from Chime in the order in which commands are
processed. In Netscape, messages are scrambled in an
unpredictable way. To solve this, at my request, Tim Maffett
numbered the messages, and I wrote a large amount of code (over
400 lines exclusive of comments) to unscramble them (see Design Features, also unscramb.txt,
scrambld.txt, unscramb.js, all in the shared folder).
In IE, Paul Pillot reported that messages are not scrambled. However,
in my tests, even small numbers of messages seem to come back in reverse
order (last first). Therefore, the IE message stream is also being
processed by the unscrambler -- this seems to do no harm and it didn't
seem worth the time to do further tests to fix what wasn't broken.
No changes were needed to the unscrambler code.
- .pdb file loading kills remainder of script.
Many scripts begin with a "load pdb" command, and continue with rendering
commands. These work fine in NS. In IE, any command that accesses a file
(namely load "file.pdb" and script "file.spt" commands) stops script execution
-- the remaining commands in that script are not executed.
For .spt files, the remaining commands cannot be resuscitated. In contrast,
script was sent via IMBIF, Paul Pillot discovered that the remaining commands
are resuscitated when another file access command is received by Chime,
AFTER that command is executed. For example, if the first script is
the result is a wireframe display of oxyhemoglobin. If this is followed by
the result is a spacefilled, green ATP! If, instead, the second script is
where the "dummy.spt" file contains only one line, a comment, the result
is a green spacefilled hemoglobin.
The behaviors described above are based on tests from local files.
There is some evidence (transient wireframe display during molecule loading
in PE) that behavior on-line from a server is different. Details have
not been documented.
- Loading and FirstView rendering
of PDB files in PE was redesigned to accomodate the above
- Detecting script completion. Because "load" commands
stop script execution, exception code had to be installed to
detect the completion of a load command. In NS, the message stream is watched
for a special End-Of-Script (EOS) message that is added to the end of all
scripts in a comment. In IE, the load commands prevents the comment from
being messaged. Paul Pillot inserted code to detect a message that does
come back, namely "Chime script completed.", and to signal the end-of-busy
condition only when preceded by a message that begins "Requesting"
(which occurs only for load and script commands that request files).
This code is in file msgcall2.js. I added a new function
send_load_script() (in s2c2.js) to handle load commands. In IE,
it doesn't append the EOS signal (since it has to be handled differently
and would end up coming out later and confusing the busy/ready controls),
while in NS it does.
- Some .spt files converted to script strings.
So many problems were found
conveyed via IMBIF
(e.g. those that render the first view in shared/loadit2.js).
In other cases. the existing .spt files seem to work reliably
(e.g. in DISPLAY, Contacts, the "cont*.spt" files in shared).
- Explicit newlines or semicolons required in command script strings.
This concerns the format for command scripts sent to Chime via IMBIF,
as JS strings. In both NS and IE, commands can be delimited either
by newlines alone, or by semicolons alone (or by both).
In NS but not IE, literal newlines, escaped with backslash, become newlines in
the string. For example
contains two newlines in NS, but not in IE. In IE the above string is
In order to get the command string to work in IE, either semicolons
must be added after each command, or \n must be inserted, like this
Hope I got them all!
- history.length is used in a few critical places in PE.
Lengths in IE are one less than in NS for the same "length".
Exception-handling code was installed to deal with this.
- Distinct names required for concurrent Chimes.
In NS Protein Explorer, each Chime was named "chime_graphics" (the bottom
one in Comparator, "chime_2graphics"). However, PE assigns a number
to each session, and opens a distinctly named window for each session.
Each window name contains the session number, plus "F" if PE is being
run from a downloaded local Files, for example "PE_Win_F01".
(The "F" distinction allows on-line and off-line
PE sessions to run concurrently.) In NS, the distinct parent window names
were sufficient to keep the Chime objects in two sessions separate, even
though the Chime names were identical. In IE, distinct Chime names
were required, so the names are now, e.g. "chime_graphics03" (for
the 3rd Explorer session on-line) and "chime_2graphics01F" (for
the bottom Chime in the first off-line Comparator session).
In NS, you can right click in the gray border around Chime and View Source
but not the actual code generated.
Less Critical Issues Mostly Fixed.
- Project Folders.
It is possible to set a Project Folder in IE, and run rendering
scripts. Because of bugs in the Chime/IE combination, there are
severe limitations. Details are provided in
Using Chime Command-Script Files in Protein Explorer's Project
Folder with Microsoft Internet Explorer (PE/IE).
- Newlines in alerts. In NS, strings containing backslash-newlines
display in alert() and confirm() messages with the newlines intact.
In IE, the newlines are lost, so they display without newlines (very wide)
and with words joined lacking spaces. These were fixed where noticed
but some may have been missed.
- Opening an optimally large (1024 x 768 pixel)
window for each new session has been improved and streamlined.
In most cases, PE will now open directly, without the intermediate
request asking for the user to ensure that the window is adequate
that formerly occurred for every session.
Neither NS nor
IE appear to have a mechanism for opening a new window that is
maximized. Both can determine the screen size by the same mechanism
determination of the size of an already-open window differs
(e.g. window.outerWidth in NS vs. document.body.clientWidth in IE).
By default, PE now
opens a window the same size as the screen, unless the screen is
larger than 1024 x 768 pixels, in which case it opens a window
1024 x 768 (because that is adequate).
If the screen is smaller, PE recommends increasing the screen resolution.
There is a checkbox on the FrontDoor that is
checked by default. If unchecked, it lets each browser open its
default window size. For NS, if the last window closed was
maximized, then new windows are maximized by default; but for IE,
new windows are never maximized and are always smaller than the
parent window. Instructions for the user are provided in a
new document Window Size Control in PE.
When the checkbox is unchecked or the screen size is too small,
explanations appear automatically in a resizable window.
- NS and IE use different parameters to place the upper left corner
of a newly opened window (screenX,screenY vs. left,top respectively).
A function ul_corner(x, y) in util_top.js was created to handle this.
- Catch 22. The different method used by IE to report the size of an existing window
(document.body.clientWidth is the only method known to me)
has a catch-22 consequece. If you want the content of a document to
depend on the size of its frame, you can't find out the size of the
frame until after the document is loaded! So in cmd2way2.htm, I resorted to
first loading a blank document and placing the size of its frame in
top-level variables, then loading the real document referencing those
- Embed commands follow script file.
When coming from a server, if the initial view comes from a script file
Chime's embed tag (in pe_proj.htm) are executed after(!) the
script file commands. This is not true when run in local mode!
And not true in Netscape.
To prevent the embed commands superceding the script, I removed
bgcolor and startspin from the embed tag. This caused no problems
because the intial view script already included background and spin commands.
Command scripts for Chime that display multiple images with refresh commands
commands. The flickering (or "jumpiness" or "static") occurs in IE only,
not in Netscape. Such scripts were originally used in animations generated by the
displayed the current model number in a form slot during the animation.
When the cause of the flickering problem was finally identified
in December, 2002, the model number display
was removed from the animation windows to enable the animations to run
smoothly in IE.
Minor Inconveniences Unfixed.
We can live with these for now, so they weren't fixed.
- Command recall. In Netscape, you can recall previously
entered commands by typing comma (,). The command appears in the slot,
but the cursor remains at the left end of the slot. This means that
you can press comma repeatedly to scroll through prevous commands.
In IE, the cursor goes to the end of the recalled command. This means
you have to press Home before another comma will recall the next command.
- Transient wireframe rendering when a new molecule
is loaded, before the firstview rendering appears.
Paul Pillot came up with a cute trick to avoid this. Unfortunately,
this trick works only when PE is operated from local files in a downloaded
copy, so on-line, you still see the unwanted wireframe for a moment.
Paul's trick was to first send this script:
followed by the load command. The load command, being a file access (see
above) triggers the post-.spt commands in the previous
script to execute AFTER the load command -- hence to hide the wireframe
before Chime completes execution of the "script". This is what I call
convoluted and devious code! Wonder what it will do when and if MDL
"fixes" Chime's behavior in IE?!
Can't Be Fixed.
Beyond my control.
- Closing the second of two (or more) windows containing Chime causes a
Plugin Error that occasionally crashes IE. See
Tips for more (warning displays in tips
document only if you are using IE).
- Animations are jumpy. A red warning appears at the top
of the Animations window (created from the NMR Models/Animation page)
when you are using IE. Netscape displays animations much more smoothly.