FF Nightly 51.0a1
Tested on Mac OS X 10.10, Windows 7 x32, Ubuntu 16.04 x64.
[Steps to reproduce]:
1. Go to https://webrtc.github.io/samples/src/content/peerconnection/pc1/ click Start and share you devices.
2. Click on "Share Selected Devices".
3. Refresh the page.
Page is refreshed and you can click on "Start", camera starts capturing.
"Start" button is inactive and can't be clicked.
I can reproduce but this seems to be a bug of the test page, not a Firefox bug.
Note: if reload with Shift+Cmd+R instead of just Cmd+R, I can't reproduce anymore.
I tested again ussing the same test page and after the second refresh (Shift+Cmd+R) the "Start" button is inactive. Please try to refresh the page multiple times to see if you can reproduce it.
(In reply to ovidiu boca[:Ovidiu] from comment #2)
> I tested again ussing the same test page and after the second refresh
> (Shift+Cmd+R) the "Start" button is inactive. Please try to refresh the page
> multiple times to see if you can reproduce it.
I tried at least 5 times and can't reproduce when I shift+reload.
Using Firefox Nightly 51.0a1(2016-09-04) on Mac OS X 10.10 and Windows 10 x64 I can reproduce this issue, with new profile no add-ons. If I open the same link in a new Tab everything works until I refresh the Tab.
I reproduced the issue with Firefox 51 beta 1 under Ubuntu 16.04 64-bit.
Only if I hard refresh the page (Ctrl+Shift+R or Ctrl+F5), I can click the Start button again.
Reopening since this works fine on Chrome 54.0.2840.90 under Ubuntu, with F5 or "Reload this page" button from toolbar.
Is there anything known that this test page could be doing that would work on Chrome but not on Firefox?
It appears simply a bug(?) in the page, depending on how much dom state survives a reload. On 'start', start() is called, which disables the button. Apparently that survives a simple reload (but not a shift-reload). main.js initializes callbutton.disabled and hangupbutton.disabled, but does nothing with startbutton.disabled.
Longstanding tradeoff of restoring form state on reload...
If a site modifies fields the browser might cache, it should initialize them and not depend on defaults (i.e. set disabled=false where it sets disabled=true for the other buttons)
*** This bug has been marked as a duplicate of bug 654072 ***