Known JS Bugs and Fixes

#1 How to Avoid JS Bugs in GPC?

Before learning about dealing with JS bugs in GPC, here is how to avoid them altogether. This procedure basically describes how the GPX-Files pages are currently created and maintained.

  • use Firefox to avoid GPC browser bugs in IE
  • prepare the HTML code for each one of the GooglePage fields in an external editor
  • create a new empty GooglePage in GPC
  • use HTML Editor window to paste the prepared HTML code into each field
  • do not use the WYSIWYG interface to edit any fields with JS code or custom formatting options
  • note that most of the active JS content (e.g., AdSense) will not be actually displayed in the WYSIWYG window, which is normal, in fact, desirable behavior (see GPC JS execution bug description for details)
  • "Publish" the GooglePage, but do not go "Back to Page Manager"
  • use the "View Live" link to look at the published page
  • if any changes need to be made, make them in the external text editor and paste the revised HTML code into the appropriate fields using the HTML Editor window
  • "Publish" the page and "View Live" to examine it again
  • repeat the last two steps until the published page looks as desired
  • save the final version of the HTML code for each field in the external text editor, use remote backup if necessary
  • use "Back to Page Manager" when finished
  • the GooglePage with JS code has been created!

Do not open a GooglePage with active JS elements for editing in GPC, because JS may become corrupted. If later the page needs to be edited, delete the existing page and re-create it from scratch as described above (using the backup or revised HTML code).

Top

#2 Browser Compatibility

Firefox

GPC, like most other Google products, works best with Firefox 1.5+.

Overall, Firefox 1.5+ produces the best and most consistent results for creating, editing, and rendering GooglePages. Accordingly, the instructions on this site assume that Firefox is the browser used to create and edit pages. There is one special case, however, when a filed or an entire page becomes uneditable in Firefox and IE must be used to edit and/or "reset" the affected page.

IE

IE 6+ appears to run a version of GPC slightly different from that used in Firefox. The IE version of GPC actually still does remove JavaScript from pages, albeit only in a special case.Conversely, when a field becomes uneditable in Firefox, a page still can be opened and edited (or cleaned up) in IE. In fact, this is how the default "home" page for this site has to be edited at this point.

The IE version of GPC also has a few odd visual bugs (or maybe features?) For example, in the HTML Editor window, tags appear in all-caps in IE, but in lower-case in Firefox. And WYSIWYG window in IE actually attempts to display some types of active JS elements. For example, if a page contains AdSense code or other active JS code, some type of output is displayed at the bottom of the WYSIWYG window, as the following five sample screenshots show.

GPC in IE: Active JS Bug Screenshot GPC in IE: Active JS Bug Screenshot GPC in IE: Active JS Bug Screenshot GPC in IE: Active JS Bug Screenshot GPC in IE: Active JS Bug Screenshot

It is not clear whether the ads count as those from the AdSense account used on the page, or as Google's own. Of course, since AdSense explicitly forbids account holders from clicking on their own ads, the former case would make little sense, but as these ads are shown in the WYSIWYG window, page code is not available for inspection. Perhaps, this is a glimpse of Google's plans for making money on GooglePages—showing ads to the content creators rather than users. An idea not unlike the current approach on Gmail.

Page Viewing and Rendering

Fortunately, the browser specific bugs affect only the WYSIWYG window of GPC—preview and published pages display JS elements correctly in both IE and Firefox. GPC does not support Opera yet, and when viewing GooglePages, Opera renders them almost like Firefox does, but not quite, so if a GooglePage relies on some fine alignment of graphical elements, it may appear a bit odd when viewed in Opera.

Top

#3 Uneditable Field

After JS code has been added to a field, it can become uneditable in GPC. No dashed outline appears around the field in GPC WYSIWYG window and the field cannot be selected for editing.

Only fields that contain JS code become uneditable, but it is not clear if any specific type of JS code is more likely to cause this problem. Interestingly, the JS codes in affected fields continue to function correctly, but the content of those fields can no longer be edited in GPC. In a worst case scenario, the page itself effectively becomes "locked" as its WYSIWYG preview cannot be opened.

Typically, this bug becomes activated at least several hours after a page has been published, but the amount of time this effect takes to develop is rather unpredictable. For example, pages deleted and immediately re-created activate this bug the first time the page is saved and re-opened in "Page Manager." The majority of pages on this site have developed this problem eventually, but it is not a fatal problem.

Possible Work-Arounds

Switching layouts (not "looks") is the easiest practical way of dealing with this problem in Firefox. If the affected field (e.g., a sidebar) becomes editable in one of the layouts, its source HTML can be edited in that layout, and then the page can be switched back to the original layout. Switching layouts is a very safe work-around to attempt, because the content of a field is not lost or altered when that field is not displayed in a particular layout. Some fields, e.g., footers, may remain uneditable in every layout though, in which case switching browsers should help.

Switching browsers is another safe and effective work-around for uneditable fields or otherwise "locked" pages. Pages that don't open or contain fields uneditable in Firefox can be edited in IE. Because of the IE browser bugs, it may be advisable to simply delete the content of the affected fields, "save" the page, and then re-open it for editing in Firefox. This way, the continuity of the site is maintained, as there is always a published version of the page. Note that GPC should not be running simultaneously in two different browsers because it may cause errors when saving or publishing pages.

For any page other than the default "home" page, there is always an option to delete the affected page and then to re-create its contents. This is the fastest and preferred work-around, if the HTML code for all the fields on the affected page is backed up externally. Making page copies in GPC Page Manager is not a viable method of backup in this case, because copies degrade just as the original pages do.

The default home page, however, can not be deleted, and thus if switching layouts fails to activate a particular field, the only remaining solution is to switch browsers, as described above.

Top

#4 Enkoder Script Example

The following screenshots illustrate the effects both the uneditable field and GPC JS execution bugs on the Enkoder Script JS (see the Enkoder page for details).

Enkoder Page Screenshot Before GPC JS Bugs Enkoder Page Screenshot After GPC JS Bugs

#5 GPC JS Execution

This is a problem encountered for JS that produces text or graphical output. When a page is edited, previewed, saved, or opened in GPC, the JS code in it is executed and its output is saved into the HTML source code. See examples of this bug on the Broken Bitty and Enkoder pages.

Note that when active JS content does not appear on the WYSIWYG view in GPC (Firefox), it means that the code definitely has not been affected by this bug. Conversely, if an active JS object is displayed in the WYSIWYG window, it is likely that it has been affected and should be re-pasted into that field.

Is It Spontaneous?

It appears that this bug is not spontaneous, i.e., a page with JS needs to be edited, previewed, saved, or opened in GPC to activate it. In other words, there does not appear to be a Google bot that patrols "published" GooglePages and cleans out or randomly executes JS code on them. The bug also appears to be field-specific, i.e., editing other fields on the same page typically does not activate it (but since saving the results might, it's a moot point).

Possible Work-Arounds

The spontaneous execution bug is more of a nuisance than a real problem, because it can always be corrected by re-pasting the JavaScript into the HTML code. An advisable way to proceed is to test all the relevant parameters of the script and its <DIV> wrapper (position, size, color, etc.) on a separate test page. Once the final version of the code is ready, it can be pasted into the real page and "published" without further editing.

If this bug occurs in a field that has also become uneditable, see the entry for uneditable field bug.

Affected JavaScript Code

  • Even Simple JavaScript code, such as browser detection with text output, can be affected.
  • Hit counters are particularly susceptible to the effect of this bug, accordingly the StatCounter tutorial recommends using the "invisible counter" option.
  • AdSense text objects can be affected, so it is advisable to paste the AdSense code as the last editing step before "publishing" a page.

#6 IE Empty Field

This bug is the simplest to describe and to avoid. The IE version of GPC automatically removes JS code if that JS code is the only content in the field. The code is removed automatically when the HTML Editor window closes, as can be seen from the default "click here to..." text that shows up in the field afterwards.

In IE, the only apparent work-around is not to add JS code to otherwise empty fields. If for some reason it is essential that a field contains nothing but the JS code, it can be safely pasted into that field using the Firefox version of GPC.