59.54 KB, image/png
16.39 KB, image/png
15.58 KB, image/png
5.97 KB, patch
Mark Mentovai: review+
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: 2005122909 (1.0b2) I use a variation of this script in other Mozilla based browsers to show a custom dialog box on screen. On Camino only, this script produces a stray checkbox in the middle of the custom dialog box. Reproducible: Always Steps to Reproduce: 1. Type 'about:config' in the address bar. 2. Type 'signed.applets.codebase_principal_support' in the Filter. 3. Ensure that 'signed.applets.codebase_principal_support' is set to True. 4. Go to the URL provided (www.trafficofficemanager.com/Camino/customDialogCheckboxBug.html). 5. Click on the button that says 'Show Bug'. 6. When asked to authorise the script, click 'Allow'. Actual Results: A custom dialog box appears on screen (as it does in all Mozilla-based browsers that I've tested this script on). In the middle of dialog box, however, is a stray checkbox. Expected Results: All other Mozilla-based browsers I've tested show the custom dialog box as a regular dialog box (no checkbox). I primarily use Firefox 1.5 / Windows, but we're also regularly testing on Firefox 1.5 / Mac, Firefox 1.07 / Windows and Mozilla 1.7.12 / Windows.
Is this the same as the bug (possibly unfiled) that causes a useless checkbox to appear when changing pref values in about:config? cl
This could well be the same "stray checkbox" we see in about:config sheets. Is this related to XUL (and maybe to the MathML mess where it was throwing XUL dialogues)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see a "remember this decision" checkbox and some partially cutoff text, but it's not that bad. Benjamin: were you using a recent build (like 1.0b2)?
Created attachment 209942 [details] screenshot of the correct (custom) prompt smfr, that's the wrong sheet (although it is cut off, which is prolly another bug); it's the sheet after that one that has the stray checkbox.
Created attachment 209943 [details] "matching" sheet from about:config Here's the "matching" version from about:config (double-click a string pref to see it).
The nsIPromptService API says that we should hide the checkbox if the checkMsg argument is null. In the original testcase, it's an empty string, so we show the checkbox. In the about:config case, it is null, and I have a fix to hide it in that case.
(In reply to comment #7) > The nsIPromptService API says that we should hide the checkbox if the checkMsg > argument is null. In the original testcase, it's an empty string, so we show > the checkbox. In the about:config case, it is null, and I have a fix to hide it > in that case. Should we also hide it if an empty string is passed? I haven't dug too deeply into that code, but is there any reason an empty string should generate a checkbox too? cl
Created attachment 209984 [details] [diff] [review] Patch Patch hides the checkbox if the checkMsg string is null or empty
Attachment #209984 - Flags: review?(mikepinkerton)
Wow, that was fast! Thanks everyone. Simon, I'm using 1.0b2. I'm rather new to this whole bug reporting thing. Is this the end of the process? How does this bug get closed now? Am I responsible for closing it? Should I wait until it has been reviewed?
Benjamin: nothing more for you to do at present. I'll check in the changes once it has review, and you can pick up the next nightly build and test. If you like, you can mark the bug Verified when you see it working.
Comment on attachment 209984 [details] [diff] [review] Patch r=me, but I'd like to see comments with each use of *checkMsg indicating that we know the nsIPrompt interface says null when it means null or "\0" when.
Attachment #209984 - Flags: review?(mikepinkerton) → review+
Status: NEW → ASSIGNED
Target Milestone: --- → Camino1.0
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed18.104.22.168, fixed1.8.1
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.