If you go back in the history to a page that was the result of a form post (e.g. filing a new bug in bugzilla), you'll get a dialog asking if you want to repost the form data. This is completely wrong. If you click No, it will end up showing you an error page instead of the page you saw before when you originally completed the post. This is really bad because users can lose valuable data. I lost my bugzilla bug number (which wasn't a big deal), but you might lose an airline ticket confirmation number or something.

Nominating for rtm.

This is a tricky one. Please see 43123,46338. Work should be done in docshell possibly with some interaction with cache. Automatically reposting (while going back or forward) causes bad things like purchasing a ticket twice. Not automatically reposting fails some pages like amazon.com's search page(bugzilla bug # 1718, 17685). THere is a suggestion to use a 3 button dialog, with "yes" for reposting, "no" for don't repost, "cancel" -do nothing don't leave the current page. There is also a suggestion to not automatically repost for back and forward, but repost for reload. If we do this, we need to have a interim page(just like in Nav 4.x) instead of a dialog, that sez the page was a result of a post and if the user wishes to repost the data, he press the reload button. The work involved spans beyond Session History. cc'ing appropriate enginners and phil who was recently bitten by this.

Radha, considering how close we are to ship, can we realistically justify changing this behavior at this point?

I think whatever fix we come with can be justified as long as it is right. I know a lot of people hate that dialog. The problem is figuring what the right behavior is, considering all the cases that have to be covered. If someone who knows how this exactly works in Nav 4.x can do a brain-dump to me, I'm willing to spend some time on it.

Note that even with the dialog I can't get the behavior I want. I just want to see the result of my last form post. When I clicked the button to not repost the data, I got some kind of error page from bugzilla (the one with the big red box), saying that I didn't submit the right fields to update the bug.

nav triage team: since the back button is the most used button, lots of users will eventually run into this problem, and the work around is undiscoverable, dialog does not make sense. So P2. Let's implement Radha's suggestion Yes, No, Cancel. Vera will write the text (because the biggest problem is understanding this). Radha, Don thinks that we need to get a patch and super review by Monday to get this in. Note that if adding a third button (Cancel) takes too much time, we want to take the text changes from Vera. So we want text changes, and possibly adding the Cancel button if we can. cc'ing verah and jaimejr for l10n.

Adding Michele and Monste to cc: list. I would vote for getting these changes into RTM. People use the back button "alot".

is bug 52635 a dup of this?

Note that we should not ask users at all wheather to repost the form, if we want conform to RFC 2616 (HTTP/1.1). Instead we should redisplay the page without reposting. See my latest comment in bug 43123. Actually this bug seems to be a dup of bug 43123 and/or bug 46338. Bug 52635 is a slightly different issue. I don't think that we need full conformance to RFC 2616 in RTM, but the broken behaviour of the Cancel button (performing a HTTP GET on the page instead of doing nothing at all) should be fixed in RTM. More discussion on that issue is in bug 46338.

I have to agree that the dialog makes no sense. We should always just redisplay the previous page contents, and never repost. No dialog is needed.

It's getting to later to fix this and get it approved for N6 RTM. Especially since we don't have consensus yet. Sorry. Minus.

Let's try to get this for 6.01...It's really annoying.

I'm working on a fix as I type this. Please hold on..

I removed the dialog code. Taking the bugzilla example, I made changes to a dummy bug(56221) 1) If I don't repost, you will see that error page from bugzilla. (The symptom warren has described when he first reported the bug). This is the same behavior as "Cancel" in the dialog. 2) If I repost you can go back to the bug exactly where you were with form values retained. However if you press forward now, you will get a mid-air collision with your own changes to the bug before you clicked Back. I think the same actions (submit form, go back, go forward) on a site that sells tickets will result in double purchase. When I go back/forward to any page(with or without post data), I'm passing the VALIDATE_NEVER flag to the channel. This will try to retrieve the page from cache. I understand form post results are not saved in cache. I'm yet to try the combination of repost, no repost with FORCE_VALIDATE flag. Shall try that out comment in the bug again.

Few corrections to my previous comment: 1) Load bug 56221. Make some changes to the bug 2) Submit changes. 3) results of form submission occurs(Followed by the next bug in your list, if you already did a query before you went to 56221) 4) Now I hit back button. When not reposting: ------------------- I go back to the bug page. When Reposting: --------------- I go back to the bug page. 5) Hit Forward button: When not reposting: -------------------- Bugzilla error when reposting: --------------- Mid-air collision.

Restoring need info. Radha, get the fix and the reviews ASAP!

> I understand form post results are not saved in cache. They should be saved in memory cache or by some other mechanism. I filed bug 56346 on that issue.

using FORCE_VALIDATE seems to have no effect on the behavior. I'm getting the same results as in the comment I made today at 15:04.

Okay this may be out in left field, but there is a third option to "Full repost with postdata" and "Broken POST with no postdata". My feeling is that we should offer the user two choices: Okay) If the user clicks Ok, repost fully Cancel) If the user clicks Cancel, load about:blank We should not be sending a POST request to the server without the post data. No sites are designed to handle this because no browser does it (except us). It seems better to show the user nothing (about:blank) rather than to show them an error message or the wrong page of a site or <insert random thing here>. Of course the long term solution is to mimic Nav's behaviour or follow RFC 2616 but we are running out of time. On the off chance this seems doable, this is what I see of Nav's behaviour: For a session history load (not reload): Does this entry have post data? No: Do the regular thing. Yes: Does a cache entry exist for this page? Yes: Display it No: Change URL to load dummy page "Data Missing: ... recreate the document by pressing the reload button." (Notice the behaviour of the first "Yes" changes from "Pop up dialog" to this cache || dummy load - this makes pressing the Back button much less painful) For a Reload: Are we displaying the dummy page? No: Do the regular thing Yes: Pop up dialog For the dialog: Okay: Repost the URL complete with all post data Cancel: Abort and do not load any URL or post anything

Another way to handle Cancel might be: Cancel) If the user clicks Cancel, load resource:///res/data-missing.html Where data-missing.html says something like: DATA MISSING This page is the result of a form post and cannot be displayed at this time.

After going thro this bug and all other related bugs, I think it is not appropriate to blindly "post or not post" the data with out warning the user about the consequences. Until 56346(the bug this depends on) is fixed, it is not possible to imitate the Nav 4.x behavior. Instead of surprising the user with a double post or a error message,I intend to keep the dialog with better wording and better action. After going thro' bug 43123(wording for repost dialog not OK), I infer that the way the Cancel button behaves in that dialog is in-appropriate. I intend to fix that problem and add better description to the dialog. So, the dialog will be a 2 button dialog. Pressing "yes" will repost the form data. Currently we do not cache the post data results. So the query will go to the server and it will cause double posting (eg., mid-air collision in bugzilla pages). Pressing "No" will not do anything. It will just dismiss the dialog and the user will be where he was. We will not attempt to load the page with GET. I agree that doesn't make sense. That is something the HTTPChannel does when it can't find the post data for the cgi. I will attach the patches soon.

I have attached a patch to the bug. Please note that the patch is based on the latest trunk builds.

Text for the dialog: " If you have already submitted the data in the form on this page, clicking Back or Forward will cause this data to be submitted again. Are you sure you want to re-submit the data? [Yes] [Cancel] "

I really don't think it ever makes sense to repost the data. Consequently the dialog is unnecessary. If the user wanted to repost, they would click the button again. The reason for history is that the user wants to go back to the page they saw before -- not the latest version of the page on the server. If they wanted the latest (or wanted to repost) they'd hit the reload button (or click the button on the page again that caused the post in the first place). Reload should be the only thing that prompts the user to repost or not.

Radha's patch looks good to me. It fixes the worst misbehavior and should make it into RTM. Further improvements to the UI can be done later. verah: your text isn't quite correct: - the dialog appears after pressing Reload, too - the form is not "on this page", but on the previous page - clicking Back or Forward will cause the dialog to appear My suggestion for the text: " The page you are requesting was the result of submitting data in a form and may have caused some additional action. Are you sure you want to re-submit the data and perform that action again? [Yes] [Cancel] "

Non-super review r=adamlock. Patch looks fine to me.

Spoke to Verah about the wording. She is trying to come up with something better, since the dialog would show up whenever the user uses back/forward/reload/go menu and may not necessarily remember that he is going to a page that has post data results.

Okay, let's try this: " The page you are trying to view processes data you entered in an online form (such as an order form or a membership application) earlier in this Netscape 6 session. If you view the page, the data will be re-submitted. If you wish to re-submit the data, click Yes. "

sr=rpotts This patch looks good to me. Post RTM we need to deal with bug #56346 which is why the page is not being cached :-)

PDT, we have the review and approval now. It looks good.

Verah provided me with a slightly different wording on IM. Here's what she provided me.. The page you are trying to view processes data you entered in an online form (such as an order form or a membership application) earlier in this Netscape 6 session. To view the page, re-submitting the data, click Yes. Otherwise, click Cancel.

PDT says rtm need info: Please attach dialog wording changes as a patch, need msanz approval for them too. Would take current patch without wording change.

PLEASE: Go Forward/Go Back should not have dialogs!! The user should see what they saw before in the history. That's the way 4.x works, and that's what makes sense, and is least complicated for users. Only Reload should ask to repost.

attached patch to the wording change. msanz please review it

please, do not change UI at this point. UI is frozen, for good. Is there a way to resolve this without UI change? That would have to do it...

msanz, The UI change involves changing the wording for the dialog. The dialog was already there. It is just the wording that is different. The new wording makes the dialog more meaningful.

I understand, but the new wording means new translation, and we are past that deadline.

I have to STORNGLY agree with msanz on this one. Either minus this bug, or just take the patch without the new wording. The PDT is being very strict with us on our delivery dates for language packs, so we need to be equally strict with any suggested UI changes (i.e. No more UI changes that will cause us the go our for more translations).

PDT, I would like to check this in with out the UI changes. Please provide a approval. Also, are there any objections to checkin in to the trunk with the UI change?

This is probably a stupid question... but if this dialog has already been translated, then why is it a problem to change the wording in the US version? There would be no need to re-translate.

PDT says rtm++ for patch to docshell and nsSHistory.cpp to land on branch and trunk, please land wording change only on trunk.

docshell and nsSHistory.cpp changes checked in to branch. docshell,nsSHistory.cpp+wording changechecked in to trunk.

back button now works, but forward still asks if you want to post. Hitting Cancel doesn't load the cached page - instead nothing happens.

forgot to mention my build id: linux comm MN6 build 2000101909.

jellwell, The behavior you observed is the workaround for the situation. Please see my comments on 10-13-2000 14:08. Currently, mozilla does not cache post data results. So, it can not load the page from cache. (It will, once bug 56346 is fixed) Earlier, pressing cancel used to load the page with GET and produce error messages. Now cancel does nothing (as requested in bug 53123)so that users can either surf elsewhere OR use the Go menu to go to some other page in history. Pressing forward will show up the dialog again, because the post data page was not served by the previous back/forward operation. Marking fixed, so that QA can verify the workaround fix.

Got another bug for the real fix? (Actually I think we should reopen this to keep the arguments intact.)

Note that the dialog mentions 'netscape 6' while I am not using Netscape 6. I am using mozilla. <insert rant about 'branded versions should be completely branded' here>

A minor point, but if you cancel the dialog, focus is not returned to the browser window. To reproduce: Alt-Left to back in history and get the dialog. Hit ESC on the keyboard to cancel the dialog. You now have to click in the browser window before using the keyboard. Other dialogs such as Find do not have this problem. Mozilla 101920 on NT4.

warren, I thought about keeping this bug open too. May be it can be reopened after claudius gets to confirm the fix. When it is reopened, all the rtm keywords should be removed.

Sounds good. Let's reopen it and clear the fields when he's done.

I can VERIFY That the behavior is as coded in the 2000102008 branch build namely, Submit a change to a bugzilla bug. Click back. See bug (with your comments stil in the text field, 'unsubmitted') Click forward See dialog: Click yes, Reposts data, mid-air collision. Click cancel, nothing happens. So if i understand correctly I can't go forward because we don't cache the post data results. That's great but what I really want to do is go forward w/o posting again. Why can't i do that? Are we really gonna ship like this? Bug 56346 is not even confirmed much less plussed or anything. Based on comments, I'd just reopen this now, but I want the verification to be in the bugs' history. marking VERIFIED, do what you will.

Claudius, to answer your question, in order to go forward with out re-posting to the server, I need 56346 to be fixed. Re-opening and clearing rtm keywords as discussed before. Leaving the ns601 keyword.

24 radha 1.5 repost=The page you are trying to view processes data you entered in an online form(such as an order form or a membership application) earlier in this Netscape 6 session. To view the page, re-submitting the data, click Yes. Otherwise, click Cancel. Please do not use 'netscape 6' in the mozilla tree. Also, 'a(this) that' might be ok in some functional languages but not English. I'm told to CC don, don: you're CC. I'm adding a personal mozilla milestone target. However I've been told not to make this fix myself.

*** Bug 57328 has been marked as a duplicate of this bug. ***

Quick note about this, along with saying Netscape 6, it also says "click Yes", but then gives you the options of "OK" or "Cancel", no "Yes." These are the type of bugs that are really easy to fix, but make the product look bad. CC'ing mpt cuz timeless told me to...

I know this dialog is only temporary, but if bug 56346 is not going to be fixed by RTM, then make your selection of which of the following smorgasbord of problems with it you want to fix. 1. The title should be `Form Submission' (which is what the dialog is about), not `Confirm' (which means nothing). 2. The icon should be the caution `!' icon (which indicates that the repost action is potentially dangerous), not the question `?' icon (which means nothing). 3. The action button should read `Submit' (which is what it does), not `Ok' (which the situation isn't). 4. The default button should be `Cancel' (which is safe), not `Submit' (which is potentially dangerous). 5. The wording of the message should be changed to eliminate the inconsistency between the button name in the message and the button itself (which would get you a place in the User Interface Hall of Shame), to remove the mention of `Netscape 6' (which blocks bug 14532), to avoid unnecessarily technical (and possibly inaccurate) terminology such as `online' and `session', and generally to give the user a snowball's chance of understanding what's going on. I suggest: | | "{page title}" | | This page was generated as the result of a form submission, and | {browserName} does not have a cached copy of the page to display. If you | repost the form data, any action which the form carried out (such as a | search or an online purchase) will be repeated. | | Do you want to submit the form again to see this page? As Vera said, the fact that the wording of non-English versions won't be as clear as the English version is unfortunate, but that shouldn't hold back the English version from an improvement which doesn't affect the number or usage of the strings involved. (That's why I have the page title before the string itself, rather than as part of the sentence -- it's kind of tacky, but it avoids l10n problems.) Then bug 56346 should be fixed before the wrath of eBay users, Bugzilla users, and Web application users in general, raineth down upon thee like a torrent of fire and brimstone.

Couple of things: We should not use these words and phrases: "repost" (not a word), "cached" (data shows that users still don't know what this means) and "form submission" (this sounds a bit techy; without testing I wouldn't use it). Also, we can't say "this page" because that sounds like we're talking about the page the user is currently viewing, which is not the one we're trying to communicate about. I don't like the word "session," but we need to communicate that we're talking about repeating something that happened recently. Since some actions that lead to this dialog won't be what most people would consider submitting a form (entering a username and password, for instance), when users read this they may have to wrack their brains trying to figure out what "form" we're talking about. I'd like to give them a fighting chance of figuring it out, by at least limiting the time span that they have to think about. Finally, the button names should match what we're telling them to click. If this is impossible, then the text should be changed to refer to the buttons that are actually in the dialog, even if we don't like their names. (However, my understanding is that in this case the buttons names can be changed.)

I'll change the button names so that it matches the one in the text. Again these changes will go in to the trunk.

verah: considering the comments on this dialog, should we request rtm? I would. Here's my assesment: the fix is low risk. Not fixing it results in a frequently viewed dialog which we all agree is confusing. If you don't want to check the fix onto the branch might i suggest rolling back the change to some earlier incarnation? wrt fix, I'm sure blake or I would be willing to commit to branch if this bug did earn rtm++ mpt< and {browserName} does not have a cached copy of the page to display Is that accurate, or is it actually: > and {browserName} does not keep a copy of dynamic web pages.

Vera: * Every previous version of Mozilla has considered `repost' to be a word -- but change it to `re-post' if you like. * I used `cached copy' because the only alternative I could think of (`temporary copy') provided no clue as to why the browser would have been keeping a copy (or not) in the first place. * I think `form submission' is less `techy' than `processes data', actually. * If the page title is included in the dialog as I suggested, `this page' clearly refers to the page with the title given in the dialog, rather than the page shown in the browser window. Showing the title also largely solves the problem of the user wondering what form you're talking about, so `session' isn't necessary. Timeless: Both are accurate -- the latter is more precise, but the former sounds more excusable. Take your pick. :-)

I seriously doubt if PDT will give it a rtm, since changes involve changing the language packs which have already been finalised. I believe lang-packs affect not just the foreign languages but also US-English.

Radha, that's right, wording changes are trunk-only.

> If you don't want to check the fix onto the branch might i suggest rolling back the change to some earlier incarnation? Please back this patch out.

There seems to be some duplication of effort here... bug 54492 is all about the wording of this dialog box...

*** Bug 54492 has been marked as a duplicate of this bug. ***

Thanks jake, my apologies to all on that. I suggest we use this bug for the development. In the event the other bug is unduped and we roll this one back, that bug becomes invalid so i'm marking this bug as blocking bug 54492. Yes I'm very sorry for messing up the separation but please don't undo the link, had it been in the bug when I came to it I wouldn't have dumped here. Ben: although outsiders have offered to help the originators have not. cc brendan. I think if i finish working on my maximize bug I might work on this one. *sigh*

Although to my disappointment the wording change was not approved for checkin in to the branch, I do not believe that the fix that was made for this bug in to the branch should be rolled back. I'm working on getting that "Netscape 6" out of the wording in the dialog that was checked in to the trunk. I will be checking in that after I attend to my rtm bugs.

Clearing status whiteboard. Reopening the dupe, to track the separate issue.

*** Bug 58649 has been marked as a duplicate of this bug. ***

This bug is IMO currently the worst bug in the browser. It renders Mozilla useless for anything that forms were intended for. Many "forms" actually have several steps, one on each page. It often happens that you notice you did something wrong (or you just wanted to try out a value), and want to go back to the last step. Now, if Mozilla reposts, it usually horks the session the server keeps - you have to start all over. If you requested e.g. an account name, sometimes, the account name is then "taken", and you have to find another one. Note that this are no mode-up horror stories - I've encountered such problems sevreal times. I guess you could indeed construct horror-stories where you purchase twice or similar, if the server doesn't explicitly protect against that. Personally, I think, this bug shouldn't make it into N6.0. I guess, it's too late now, but adding rtm keyword anyway.

relnote-user: don't press the back button after you submit a page; you'll regret it.

Minusing this again. We're not backing out the change.

So, wait. Is this bug now not about the dialog box? My impression is that this is now about not having a dialog pop up at all when back is pushed (view from cache instead). And, if one wants to repost form data, reload should be pushed. Someone confirm this? If this is actually what I think it is, I suggest making this change for mozilla0.9 and the first bugfix release of N6.

I also thought that this bug was to make us do the right thing (at least as well as 4.x did), not to pop up a clearer dialog about which variant of the wrong thing we should do. If not, then we need another bug on doing the right thing, which seems silly -- why not just use this bug since it already has all the comments in it on why this is important? Though of course it's nice to have a clearer dialog until the real problem is fixed.

I agree. IMO, this dialog should go away *ASAP*. Please don't spend time improving it, rather making it go away.

This bug is to come up with a real fix for the problem. I intend to keep it open for that purpose.

*** Bug 43123 has been marked as a duplicate of this bug. ***

Added self to CC.

*** Bug 52635 has been marked as a duplicate of this bug. ***

Please remove "Netscape 6" from the dialog... I was going to report a bug on it before I discovered this bug, It's confusing and it's just a two words change. IMHO this should be fixed ASAP even if the dialog is going to be removed latter. We don't need even more people confused with the Mozilla/NS difference. Thanks.

The wording of the dialog is the subject of bug 54492.

Adding cc to self

Adding me to cc:

Removing myself from list of cc's.

nav triage team: yes we must fix this in the next release.

adding dep to 32293

*** Bug 63570 has been marked as a duplicate of this bug. ***

*** Bug 64548 has been marked as a duplicate of this bug. ***

do we have an eta on this bug?

*** Bug 65021 has been marked as a duplicate of this bug. ***

i hope my extensive comments in (dupe) #65021 don't go to waste towards this discussion. btw, thanks for responding quickly, you guys. you seem on the ball!

nav triage team: Marking nsbeta1+

*** Bug 67189 has been marked as a duplicate of this bug. ***

*** Bug 57880 has been marked as a duplicate of this bug. ***

Any hope of getting this for Mozilla 0.8 instead of 0.9? As someone said, this is probably the worst bug in Mozilla/NS6 from a user perspective. It is, after all, P1, dataloss and nsbeta1+! Is anyone actually working on this?

54346 needs to be fixed before the UI can be removed and SH can hook in to the cache backend. unfortunately 54346 has not received any attention.

Sounds like you meant bug 56346. Also, this bug should not block 14532 or 54492 anymore, since the reference to N6 was removed. I remember gagan or someone said that they were working on the cache backend, and this also depended on that. Do we know of what progress they are making? I would add gagan to cc, but I don't remember for sure that he was the one working on the cache.

Doesn't [nsbeta1+] imply [nsbeta1+] for all blocking bug, too? Can anyone from Netscape update the other bugs, please?

56346 (the bug this one depends on) is marked for mozilla 0.9. So, this one will also be at the best mozilla 0.9 or later, depending on when exactly that gets fixed.

56346 has been marked dupe of 20843. Changing dependency.

IMHO this depends more on bug 40867 than on bug 20843, because if I understand it correctly, bug 20843 is about cacheing the data sent to the server in the POST request while bug 40867 is about cacheing the result of the request. Adding dependency.

adding imarsman, from bug 60218.

i would like to know why there isn't an option other than reloading and cancelling - how about just viewing the cached HTML again? not having this option makes repeatedly returning to a list of search results painful.

It *isn't* cached. I don't know where the problems are, but they may be related to bug 69731.

Just tried this out on my banking site using build 2001022221. Asks me about reposting. If I'm not mistaken, the build from two days before let me go back to the cached version of this page. I may be incorrect. In any case, now if I try to see my recent transactions, go to the "Next" page, then click the Back button, the app I am connected to recognizes I have done this and makes me log on again. The message is: This page cannot be viewed with the method you've chosen. Please use the button below to go to the sign on page (Ref. #R690). I can navigate fine, as long as I remember to never use the NS buttons (Back, Forward), just the links on the page. Choosing "view source" seems to re-request the page and gives me this message and gets me in this state as well. I don't think NS 4.7 re-requests the page on "view source".

> i would like to know why there isn't an option other than reloading and > cancelling - how about just viewing the cached HTML again? Because we don't have it anymore (at the moment). See the dependencies.

if this is only waiting on having all pages cached (bug 56346) then you can safely mark it dep/dup. 56346 should land by 0.9

Please don't mark it dupe. After 56346 lands, there is some work in Docshell to fix this completely.

Platform->All again (gagan set it to DEC)

Added dependency per radha's comment on 56346

*** Bug 72306 has been marked as a duplicate of this bug. ***

*** Bug 72684 has been marked as a duplicate of this bug. ***

*** Bug 72802 has been marked as a duplicate of this bug. ***

*** Bug 50391 has been marked as a duplicate of this bug. ***

I have attached a patch that uses the features in the new cache to obtain post data results from cache when the user goes back/forward to it. Now the dialog won't come up every time the user goes back/forward to a postdata result. The dialog will come up, *only* if the cache entry for the post result has expired from cache. It is not clear to me when a post data result would expire from cache. I used some rudimentary methods to test that part of code. unfortunately prefs is not hooked up to the new cache yet. I'm not *very happy* with throwing a dialog whenever a post result expires from cache. There are some misbehaviors in the back and forward button when the dialog comes up. I'm experimenting the idea of showing a intermediate page like Nav 4.7, instead of a dialog. Shall post details of that when I'm convinced it works well reasonably

Code looks good apart from a few small nits: 1. DEBUG_Radha 2. appstrings.properties does not end with a newline r=adamlock

I ran Radha's patch on Linux, and did a few tests on a shopping site, comparing the behavior with a pre-patched version. The patch seems to have fixed this bug. For me, this bug is one of the most annoying "features" in Mozilla and I've been longing for a long time for it to be fixed. So, please try to get this into the trunk before 0.9.

looks good... sr=rpotts

fix checked in

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]