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

Comments

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Needs review
StatusFileSize
new autosave_match_theme.patch2.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

quicksketch
he/him
commented
Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

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

hey_germano’s picture

hey_germano
she/her
Primary language English
Location Minneapolis, MN, USA
commented

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.