50.0a1 (2016-07-12) on Mac STR: 1. log into wordpress.com 2. create new post 3. start typing, then wait ~10 seconds Expected: post autosaves Actual: error that post couldn't be saved I tested in Chrome Canary, Firefox (release), Firefox Developer Edition (aurora) and no bug in those, so this might be a web compat regression.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0 I have tested this issue on Mac OS 10.11 with the latest Firefox release (47.0.1) and the latest Nightly (50.0a1-20160713030216) and could not reproduce it. After I've logged-in to wordpress.com and created a new post, when finished typing a few letters in the post, after a few seconds it autosaves successfully. Can you please retest this using the latest Nightly build and report back the results? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).
Marking this as Resolved - Incomplete due to the lack of response from the reporter. If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Please don't close this bug yet. Browser profiles contain millions of environmental conditions, so just because you cannot reproduce it does not mean it's not a bug. Also, inability to reproduce in a clean profile also does not mean it's not a bug: No user who has ever used their browser has a clean profile. Wordpress is one of the biggest sites on the internet, so it not working due to a browser regression is a serious issue. It's not my full time job to fix Firefox and make it work with every website on the internet, let alone track down regressions in site compat that our developers check in. So the fact that I haven't had time to dedicate to this is not evidence it's not a real bug somewhere in our code or in theirs. A better resolution than closing this bug without further investigation would be to reach out to broader audiences to see if they've experienced the problem.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0 I have retested this issue on Mac OS 10.11 with the latest Firefox release (48.0.1) and the latest Nightly (51.0a1-20160812030200) and managed to reproduce it only by limiting my network. After setting up the Network Link Conditioner with the following settings: Bandwidth set to max, Packets Dropped:90% and Delay: 0ms for Downlink and Uplink. When navigating to wordpress and creating a new post, after typing a few characters and waiting ~10 seconds you can observe that the error "post couldn't be saved" is displayed. Do you think this might have happened in your case too?
Yes it's quite likely I had not great network connection (like much of the world).
emilpasca, since you've found a way of reproducing this, do you think it'd be possible for you to use mozregression to try to find the regression range for this one? That'd make it easier for us to place it in the right component and get the right people on to fixing it.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0 I have retested this issue, using the settings for the Network Link Conditioner described in comment 3, on multiple releases of Nightly(51.0a1-20160907030427, 46.0a1-20160102030217, 32.0a1-20140602072051, 29.0a1-20131230072341) and managed to reproduce it, but I was not able to find a good build in order to perform a regression. Notes: I also manage to reproduce this on Chrome (v52.02743.116). I haven't manage to test this issue on older than Nightly 29.0a1 builds due to the fact that after signing into WordPress, the dashboard doesn't load. Considering that I have managed to reproduce this also on Chrome, are we sure this is a Firefox issue?
Hey dietrich, So it's not clear if this is a Firefox bug, or a WordPress bug. The information from emilpasca suggests that the WordPress front-end code is reacting to dropped network packets when it reports that error. Can I assume when you tested in the other browsers, you were in the same network conditions as when you experienced the bug?
Yep, I tested all at the same time, in the same place, on the same network.
If this bug isn't reproducible in Firefox (under conditions where it also isn't reproducible in the other browsers), I'm not sure there's anything actionable in this bug. I suppose the next time this happens, probably the best course of action is to look at the Network pane of the Developer Tools to try to see what is happening. I'm going to close this bug out as INCOMPLETE until more information or some reliable steps to reproduce arise.
At the time I reported it (comment #0), it was 100% reproducible in Nightly, but not in other versions of Firefox or in Chrome. So it could be that whatever the cause was on Nightly was backed out or fixed between now and then.