### Beta/Release Uplift Approval Request * **User impact if declined**: Various sites do not work properly, whether due to this bug (concatenating other scripts with the u2f polyfill) or bug 1553436 (minified code that uses "u2f" for a random variable or function name being broken). * **Is this code covered by automated tests?**: Yes * **Has the fix been verified in Nightly?**: No * **Needs manual test from QE?**: Yes * **If yes, steps to reproduce**: See comment 0. Also see bug 1553436 comment 0 and bug 1553436 comment 1. * **List of other uplifts needed**: Bug 1553276, Bug 1553286 * **Risk to taking this patch**: Medium * **Why is the change risky/not risky? (and alternatives if risky)**: This changes the web-facing behavior of the window.u2f property pretty substantially, but in the smallest possible way that fixes bug 1553436. This part doesn't have any other alternatives that I can see. It also changes pretty radically the exact sort of object that `u2f.sign` and `u2f.register` return. I am hoping this change is not one that anyone will notice in practice, because people just call these methods, but if sites are applying `toString` to these objects the behavior will change, and so will `.length`, etc. We could change the fix so we return actual Function objects, but that would have its own risks due to needing to hand-write the Web IDL argument conversions instead of leveraging the existing codegen. I am not sure how comfortable I would be uplifting the result to release. Though maybe I could more or less copy/paste the generated code to mitigate the risk. We could also possibly mitigate the issues I describe above by defining various things that normally live on Function.prototype or Function objects (e.g. `length`) on the new callables. There would still be some risk if someone does `Function.prototype.toString.call(u2f.sign)` (which will throw) or whatnot. I would be happier going the "paste the generated code and return actual Functions" route than trying to make things look like functions. * **String changes made/needed**:
Bug 1551282 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
### Beta/Release Uplift Approval Request * **User impact if declined**: Various sites do not work properly, whether due to this bug (concatenating other scripts with the u2f polyfill) or bug 1553436 (minified code that uses "u2f" for a random variable or function name being broken). * **Is this code covered by automated tests?**: Yes * **Has the fix been verified in Nightly?**: No * **Needs manual test from QE?**: Yes * **If yes, steps to reproduce**: See comment 0. Also see bug 1553436 comment 0 and bug 1553436 comment 1. * **List of other uplifts needed**: None * **Risk to taking this patch**: Medium * **Why is the change risky/not risky? (and alternatives if risky)**: This changes the web-facing behavior of the window.u2f property pretty substantially, but in the smallest possible way that fixes bug 1553436. This part doesn't have any other alternatives that I can see. It also changes pretty radically the exact sort of object that `u2f.sign` and `u2f.register` return. I am hoping this change is not one that anyone will notice in practice, because people just call these methods, but if sites are applying `toString` to these objects the behavior will change, and so will `.length`, etc. We could change the fix so we return actual Function objects, but that would have its own risks due to needing to hand-write the Web IDL argument conversions instead of leveraging the existing codegen. I am not sure how comfortable I would be uplifting the result to release. Though maybe I could more or less copy/paste the generated code to mitigate the risk. We could also possibly mitigate the issues I describe above by defining various things that normally live on Function.prototype or Function objects (e.g. `length`) on the new callables. There would still be some risk if someone does `Function.prototype.toString.call(u2f.sign)` (which will throw) or whatnot. I would be happier going the "paste the generated code and return actual Functions" route than trying to make things look like functions. * **String changes made/needed**:
### Beta/Release Uplift Approval Request * **User impact if declined**: Various sites do not work properly, whether due to this bug (concatenating other scripts with the u2f polyfill) or bug 1553436 (minified code that uses "u2f" for a random variable or function name being broken). * **Is this code covered by automated tests?**: Yes * **Has the fix been verified in Nightly?**: No * **Needs manual test from QE?**: Yes * **If yes, steps to reproduce**: See comment 0. Also see bug 1553436 comment 0 and bug 1553436 comment 1. * **List of other uplifts needed**: 1554354 * **Risk to taking this patch**: Medium * **Why is the change risky/not risky? (and alternatives if risky)**: This changes the web-facing behavior of the window.u2f property pretty substantially, but in the smallest possible way that fixes bug 1553436. This part doesn't have any other alternatives that I can see. It also changes pretty radically the exact sort of object that `u2f.sign` and `u2f.register` return. I am hoping this change is not one that anyone will notice in practice, because people just call these methods, but if sites are applying `toString` to these objects the behavior will change, and so will `.length`, etc. We could change the fix so we return actual Function objects, but that would have its own risks due to needing to hand-write the Web IDL argument conversions instead of leveraging the existing codegen. I am not sure how comfortable I would be uplifting the result to release. Though maybe I could more or less copy/paste the generated code to mitigate the risk. We could also possibly mitigate the issues I describe above by defining various things that normally live on Function.prototype or Function objects (e.g. `length`) on the new callables. There would still be some risk if someone does `Function.prototype.toString.call(u2f.sign)` (which will throw) or whatnot. I would be happier going the "paste the generated code and return actual Functions" route than trying to make things look like functions. * **String changes made/needed**: