This should work well for simple cases, but could conceivably create false positives if there's a click handler on the specific buttons, depending on whether event processing passes it on. Double-check if you're doing such forms along with the 'ajax' class!
* keep the notice-reply-placeholder around, but hidden
* insert things before the placeholder, rather than appending to the end of the list.
* append the active form after the hidden placeholder, so things inserted before the placeholder never come after it
* Realtime: check pre-existing notice visibility a second time after loading the HTML for a notice. Fixes bug where sometimes your own post would be shown twice because the Realtime notification arrived before the AJAX posting returned, but Realtime's AJAX fetch of the notice returned after.
Previously we threw away errore reported by the actual AJAX submission and only used whatever error the browser reported to us; this didn't help if we reached the server ok but had a problem there.
We now extract the #error if given and use that in the alert().
Also should now show 'Unknown error' instead of a crappy generic 'something died in jQuery' when we get a 200 response but bogus return data.
Missing default-cancel in the click handler allowed the event to bubble up to the body handler, where we think the click is outside of the form because the target is no longer in the form by the time we check
Now the event no longer bubbles up, as we cancel it when we're done.
* main notice form setup now encapsulated into SN.Init.NoticeForm(form) -- this can be monkeypatched by plugins to append their own setup code, as LinkPreview does
* LinkPreview now supports debugging with non-minified JS source when $config['site']['minify'] is false
* tweaked core & neo styles so 'notice-status' class gets same styles as attach-status, so we can more easily add mroe statusy things. (needs more consolidation with geo-status, etc)
* tweaked LinkPreview's preview area to use that style
FormNoticeXHR now is triggered on any form labeled with class 'ajax-notice', so those other than the traditional notice form should work as long as they handle the AJAX submission and return a properly formatted notice.
Things to watch out for:
* to determine whether the resulting notice should show on the current timeline, the JS code needs to be able to check the author and such. Keeping the existing vcard bits helps for this!
* the notice form submission stuff clears out inputs from your form -- test to make sure this behaves correctly
* error messages returned from the thingy _should_ come through, but this needs more testing for consistency
* while form components that aren't in a custom form should just be ignored, this should be tested more. (eg there's no location or attachment box for poll or bookmark plugins)
* NoticeListItem isn't currently reachable via autoloader -- touch NoticeList explicitly before calling into it for now.
This change adds the input form switcher, which adds a navigation menu
across the top of the input form, letting you switch between different kinds of input.
The input menu doesn't yet look like a nice set of tabs; it could use some love.
These have been failing for ages due to our outputting full URLs all the time, usually with the default protocol instead of the current one.
Forms would get output with an http: URL in their contents even when destined for an HTTPS page; while a regular form submission would just warn you about the secure->insecure transition, the AJAX code was failing outright and then not bothering to fall back to the regular submission.
I found it was easy to detect the mismatch -- just check the target URL and the current page's protocol before submitting.
Since failing over to non-AJAX submission to the HTTP URL throws up a warning, I figured it'd be easier (and much nicer for users) to just let it rewrite the target URL to use the secure protocol & hostname before doing the final submit.
This check is now automatically done for anything that calls SN.U.FormXHR() -- making most of our buttons on notices and profile/group headers work naturally.
The notice form setup code also runs the rewrite, which gets posting working without an error dialog.
I'd prefer in the long run to simply use relative URLs in most of our output; it avoids this problem completely and lets users simply stay in the current protocol mode instead of being constantly switched back to HTTP when clicking around.
(Note that folks using the SSLAlways extension to Firefox, for instance, will have their browsers constantly sending them back to HTTP pages, mimicking the desired user experience even though we haven't fully implemented it. These folks are likely going to be a lot happier with forms that submit correctly to go along with it!)
