There's something funny about the way autosave is populating the contents of the page. After restoring the contents of a form, all the fonts on the page are slightly modified (they become slightly bigger in my case). I think the replacement form must be either missing a wrapper or class; or we're replacing on not quite the right container.

CommentFileSizeAuthor
#1 autosave_match_theme.patch2.15 KBquicksketch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Status: Active » Needs review
FileSize
2.15 KB

I found the problem here is because Drupal's AJAX system automatically loads missing CSS/JS files onto the page after an AJAX request. For Autosave module, the "restore" path is not considered administrative, and so therefor the front-end theme (i.e. Bartik) has its CSS appended to that of the admin theme (i.e. Seven). To prevent this problem, we can easily just record the current theme being used and set it again using hook_custom_theme(). Patch attached.

quicksketch’s picture

Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

hey_germano’s picture

I think this might also be an issue: http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_htm...

When the form reloads with autosaved data, the CSS IDs on the form fields change to the incremented ones. For example, the div ID around one of my text fields changes from "edit-field-collector-first-name" to "edit-field-collector-first-name--2" after the autosaved data gets pulled in. So my CSS which used those IDs doesn't work.

For now I think I'll just re-do my node form CSS to use classes instead of IDs, but if I have a chance, I can look into something better.