Closed Bug 209020 Opened 21 years ago Closed 20 years ago

meta HTTP-EQUIV="refresh" broken if midas was ever used in that browser window

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ridben, Assigned: jst)

References

Details

(Whiteboard: midas)

Attachments

(7 files, 2 obsolete files)

Example that breaks meta refresh
402 bytes, text/html
Details
This ain't quite right, but it gets us in the right direction...
22.18 KB, patch
Details | Diff | Splinter Review
One step closer...
24.16 KB, patch
bzbarsky
: superreview+
Details | Diff | Splinter Review
Fixed testcase, enable editing from onload.
367 bytes, text/html
Details
Address bz's issues (diff -w).
28.52 KB, patch
Brade
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Full diff of the above.
33.00 KB, patch
Details | Diff | Splinter Review
meta http-equiv="refresh" testcase for midas
325 bytes, text/html
Details
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030530 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030530 Sometimes this meta don't refresh and after the browser don't want to mak any meta redirection: <html> <head> <title>GenWeb Version 4.0</title> <link REL="STYLESHEET" TYPE="text/css" HREF="Css/gw_acces.css"> </head> <body><meta HTTP-EQUIV="refresh" CONTENT="0;URL='gw_soft.php?CX=PIAN6552&LA=fr&BUTTON=GW_PROJECTS'"></body> I tried to put this in the <head></head> but it's the same. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3. I have the same problem on mozilla 1.3 on a PC. Works fine with Internet Explorer...
WFM 20030605 PC/WinXP. Worked in HEAD and scary enough, in BODY. (Please note that having META tags in the BODY is invalid HTML.)
I tried to put the META in the HEAD but there is always a bug
(Side note: META is deliberately allowed in BODY by Mozilla due to the number of sites that would break if we enforced the correct behavior. Reference bug 98700.)
WFM using Mozilla up to 1.5b (Buildid 2003090404) But it can confirm this with Mozilla Firebird 0.6.1: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Maybe Bug #215543 is related to this?
Example which works 100% of the time in Mozilla and Mozilla Firebird.
I can confirm this as far back as Mozilla 1.3.1 and Firebird 0.6.1 I suspect that there is other items which break meta refresh but this is the only script that i have found to break the meta refresh all of the time.
It seems, that only the active window/tab is affected. Open the link with the example for the meta refresh in a seperate or new window/tab and the meta refresh works fine.
A consistent test case has been provided and I hope this gets fixed before 1.6 goes out as it is a considerably bug.
Flags: blocking1.6a+
Blocks: 215543
Thank goodness I found this bug - thought I was going crazy as I've been using the same sites with Mozilla 1.5 for a while and this behaviour just started happening today ... The code I've been using is like: <html><head> <meta http-equiv="refresh" content="0; url=http://example.com" /> </head></html> I've tried juggling things around without satisfaction - still a mystery.
I just want to confirm Christian's comment #7 ... once meta-refresh is broken then that tab STAYS broken. Other existing tabs/windows and new ones work fine until they hit whatever the condition is that breaks them. The thing that is breaking the meta refresh is NOT the refresh itself, but something about the PREVIOUS page that took you there. In my case it's a MIDAS-based GUI editor, and in Scott's case it's the Javascript in the first page. document.getElementById('edit').contentWindow.document.designMode = "on"; If you go straight to Scott's refresh page: http://www.mozilla.org/quality/browser/standards/xhtml/transitional/meta_http_equiv.xml then it works fine. So I think this is actually a bug caused by designMode.
A further small data point - this bug does NOT affect redirects performed using the Location: header.
Changing status to block 1.6b. Breaking redirects is too high a cost for a WYSIWYG editor.
Flags: blocking1.6b+
Summary: meta HTTP-EQUIV="refresh" sometimes don't refresh → meta HTTP-EQUIV="refresh" sometimes doesn't refresh
scottmacvicar, please don't set flags if you don't know how. Thanks.
Flags: blocking1.6b+
No longer blocks: 215543
*** Bug 215543 has been marked as a duplicate of this bug. ***
So the problem here is that there is an editing session associated with the toplevel docshell, as far as I can see. This gets a state_stop notification and cancels the refresh timers (see nsEditingSession::EndDocumentLoad). The problem, of course, is that nsDocShellEditorData::GetOrCreateEditingSession sets up the editing session on the _root_ docshell, no matter which actual shell it's supposed to be set up for. No idea why it does that. Either that, or the nsEditingSession::EndDocumentLoad code needs to change. If nothing else, we need to wipe out the editing session when the midas frame goes away, no?
Assignee: general → mozeditor
Severity: normal → major
Component: Browser-General → Editor: Core
QA Contact: general → sairuh
Summary: meta HTTP-EQUIV="refresh" sometimes doesn't refresh → meta HTTP-EQUIV="refresh" broken if midas was ever used in that browser window
Referring to comment #12 and #13 I'm requesting this as a blocker for 1.7a
Flags: blocking1.7a?
joe, any cycles to look at this? can you think of anyone that can help?
Whiteboard: midas
If I remember correctly, there is no way to destroy the editor shell. We have a bug very similar to this around...
hoping we can make some pregress on this in 1.7beta
Flags: blocking1.7b?
Flags: blocking1.7a?
Flags: blocking1.7a-
closing down to ship 1.7b. no patch here yet
Flags: blocking1.7b? → blocking1.7b-
Flags: blocking1.8a?
Nominating to block 1.7 final as this is going to be the new long life branch and makes Midas a hindrance rather than a feature.
Flags: blocking1.7?
Flags: blocking1.8a? → blocking1.8a-
not a very common case. not going to block 1.7 for this.
Flags: blocking1.7b-
Flags: blocking1.7a-
Flags: blocking1.7?
Flags: blocking1.7-
I strongly urge you to reconsider. I use Firefox as a primary browser and come up with this issue daily. META refreshes are in a very wide use on the web (sites like weather.com use them). Midas-using controls are not as popular *YET*, but will become much more prevalent in the near future. Consider that most popular bulletin board software will include support for this in their new versions (I believe VBulletin already does in their 3.0 release, and it is the #1 commercial BB software out there) Given these two factors, this problem will come up more often than you seem to believe. For example, I cannot now check weather forecasts after posting to a VBulletin forum. This bug's rate of occurence will grow as MIDAS gets more widely adopted, and if it makes it into the long-lived 1.7, this could be a black eye for the whole family of browsers.
Agreed. I run into this quite often, at least several times a week and have reverted to IE until it (and some other highly annoying bugs) become fixed. If 1.7 is to become a "long lived" branch, I can't fathom bugs like this being open for a year and still not being a priority. Please, please make this a 1.7 blocker. I would really like to see Mozilla overtake IE on my desktop.
I'd say this is going to be pretty common before too long. We implemented Midas into our software (vBulletin), a Mozilla and IE based WYSIWYG editor which was well received by our customers and their users. Though the meta refresh problem is so great that we have had to add an FAQ item to our next release due to the vast number of support tickets we get regarding this. Midas was a great advancement but if this can't be corrected for the 1.7 branch then i feel it should be disabled.
Can I ask why you are using the rich text editing at a document level, instead of just creating an IFRAME in which to do the editing?
(In reply to comment #23) I fully agree. especially, since vBulletin 3 is enabling Midas now and since more an more people are upgrading to vB3, there will be more and more sites using it. Additionally its obvious, that other forum-software would follow soon (e. g. phpBB and IPB). So if you're starting to post in forums sooner or later you'll open apage using a rich text editing engine. You just have to open a thread in most cases, since many forums have the quick reply enabled, which uses a rich text editor as well (at least in vB3 and obviously sooner or later in other forum-software). In short: Sooner or later its getting hard to surf though the www without stubling over Midas.
I hate to add a "me too" but if it helps ... my application Moodle had real problems with this - we were forced to add Javascript-based redirects to make things useful again.
We do use a iframe but it still sets up the session on the root docshell.
(In reply to comment #25) In fact, we started to rely on midas in our system exactly because we support IE and Mozilla (a not infrequent target for semi-complex projects nowadays) and these two claim to support it. As a consequence, the fact that Mozilla currently claims to supports midas currently harms our ability to support Mozilla for some parts of the system. The persistence of the behavior makes any workaround we could think of too awkward.
I know this is a bad problem, but I'm trying to understand why so many pages have run into it. If you go to our demo at: http://www.mozilla.org/editor/midasdemo/ And then go to another page, there is no problem. We assumed (falsely) that this was a typical usage of Midas. What is so different about the way that our demo is using Midas vs. how other people are using it?
(In reply to comment #31) > I know this is a bad problem, but I'm trying to understand why so many pages > have run into it. > > If you go to our demo at: > > http://www.mozilla.org/editor/midasdemo/ > > And then go to another page, there is no problem. What is the other page? After visiting your demo (and touching nothing there) the refresh stops working for me; my testing "other page" was http://math.cas.cz/~geo/tmp/test.html Perhaps there is also some other factor present? Thank you for investigating the issue.
I misread this as a different Midas problem. I'm looking into this.
Assignee: mozeditor → mkaply
Mjudge did all this work when working on embedding editor, which midas reuses. http://bugzilla.mozilla.org/show_bug.cgi?id=115922 I know absolutely nothing about this code.
Mike Kaply (comment 34) -- I don't think that the bug you are referring to (specifically) is related to this bug; at least I don't understand why / how you came to that conclusion. I'd guess that the fix for this bug is to turn refresh back on when the editor is destroyed. If you can find the right place where Midas is closed (or loss of focus or ?) it should be easy to fix. (Perhaps the right fix is focus related?)
(In reply to comment #35) > Mike Kaply (comment 34) -- I don't think that the bug you are referring to > (specifically) is related to this bug; at least I don't understand why / how you > came to that conclusion. > I'd guess that the fix for this bug is to turn refresh back on when the editor > is destroyed. If you can find the right place where Midas is closed (or loss of > focus or ?) it should be easy to fix. (Perhaps the right fix is focus related?) http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShellEditorData.cpp#8 4 nsDocShellEditorData::~nsDocShellEditorData() is the best place to add it though I couldn't see what decided if meta redirects were allowed to be used.
Here is the snippet used for disabling JavaScript (nsEditingSession.cpp): // Disable JavaScript in this document: nsCOMPtr<nsIScriptGlobalObject> sgo (do_QueryInterface(aWindow)); if (sgo) { nsIScriptContext *scriptContext = sgo->GetContext(); if (scriptContext) { scriptContext->SetScriptsEnabled(PR_FALSE, PR_TRUE); } } Some other things which may be broken (but I haven't checked) are: image animation [presContext->SetImageAnimationMode(animationMode);] plugins [docShell->SetAllowPlugins(PR_FALSE);] note: image animation modes are defined in http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/public/imgIContainer.idl *************** Can someone check if image animation and plugins work after Midas has been viewed in that browser window?
(In reply to comment #37) > Can someone check if image animation and plugins work after Midas has been > viewed in that browser window? Its working fine with Firefox 0.8 and I guess, this applies to Mozilla as well. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.6) Gecko/20040206 Firefox/0.8
nsEditingSession isn't messing with the root docshell, it is messing with the docshell associating with the window 156 // disable plugins 157 nsIDocShell *docShell = GetDocShellFromWindow(aWindow); 158 if (!docShell) return NS_ERROR_FAILURE; 159 160 nsresult rv = docShell->SetAllowPlugins(PR_FALSE); 161 if (NS_FAILED(rv)) return rv;
(In reply to comment #39) > nsEditingSession isn't messing with the root docshell, it is messing with the > docshell associating with the window nsEditingSession doesn't, but nsDocShellEditorData does mess with the root docshell. There's lots of things that are pretty messed up with the way an editor hooks onto a document etc, I've got a patch that fixes this bug, but may introduce others. I'll attach it to get comments and maybe some testing too.
This patch does fix the bug, but it breaks some things when leaving a page where midas was turned on, like keyboard navigation no longer works, and pages don't always load. So something's left in a bad state, no idea what yet. Comments greatly appreciated.
This fixes the keyboard navigation problem by removing the editor controllers from the window when leaving the page. Still some issues with pageloads not fully functioning after leaving a page (note, a page where midas was turned on, not just a page where midas was turned on in an iframe inside the page)...
Flags: blocking-aviary1.0?
Comment on attachment 149484 [details] [diff] [review] One step closer... >+void >+nsHTMLDocument::SetScriptGlobalObject(nsIScriptGlobalObject *aGlobalObject) >+{ ... >+ return nsDocument::SetScriptGlobalObject(aGlobalObject); >+} *why*? :)
(In reply to comment #43) > *why*? :) Why what?
(In reply to comment #44) > Why what? returning something from a void function
Ah, duh, well, it's returning nothing, so it doesn't really matter, but yeah, it's pointless to return there...
Blocks: 198155
*** Bug 233830 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Flags: blocking1.8a1-
Flags: blocking1.7-
too big a change and too late to take for 1.0. If there's a workaround, we should get that publicized.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
The only workaround is "open a new window"... It's not very horrible, but the nature of this bug makes it tough to identify. People will just be staring at empty white pages in their firefox wondering why their favorite site's front page seems to not work in this browser everyone is so in love with. A lot of sites that have non-standard default pages still use meta redirects inside "index.html" files to point the visitor to proper locations. (weather.com doesn't seem to do it anymore, but they used to until a short while ago)
Ebay now shows up this bug when you go to bid on an item from an email link. It goes to a secure page where you log in, then it goes to a page that is a redirect. It fails 100% of the time in Mozilla 1.8a4, and also in all previous versions I had here (down to 1.3). This is a REALLY SERIOUS problem!
The only workaround is "open a new window"... It's not very horrible, but the nature of this bug makes it tough to identify. People will just be staring at empty white pages in their firefox wondering why their favorite site's front page seems to not work in this browser everyone is so in love with. A lot of sites that have non-standard default pages still use meta redirects inside "index.html" files to point the visitor to proper locations. (weather.com doesn't seem to do it anymore, but they used to until a short while ago)
Just wanted to add that it seems to affect gmail as well. Going to gmail.com gives you a META redirect to gmail.google.com - any Midas-affected window however just sits there showing "redirecting to GMail" on a white page. This means anyone visiting a fairly modern forum and then going to GMail wil run into the issue, which is probably a lot more people than was initially thought are affected by this.
Flags: blocking1.8a6?
Flags: blocking1.7.6?
Attachment #149484 - Flags: superreview?(bzbarsky)
Attachment #149484 - Flags: review?(akkzilla)
jst, is that actually ready for review?
Just a workaround I did with Javascript for those still having trouble: Create a function in your page: <SCRIPT LANGUAGE="JavaScript"> function ffredirect(){ window.location="http://somesitesomewhere.com/"; } </SCRIPT> Then anywhere else on the page call the redirect like so: <SCRIPT LANGUAGE="JavaScript"> setTimeout("ffredirect()",1000);</script> That seems to bypass the bug.
Comment on attachment 149484 [details] [diff] [review] One step closer... sr=bzbarsky assuming someone familiar with editor does the r=.
Attachment #149484 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 149484 [details] [diff] [review] One step closer... please rearrange nsHTMLDocument::SetScriptGlobalObject method to not create the nsIDOMWindow (window) until inside the if (editSession) block. I'm assuming that shell->GetPresContext() calls are not introducing leaks. I recall a while ago when nsDocShell.cpp was 2-spaces per level rather than 4 (I had to redo a patch that had 4 spaces instead of 2). I see that the file is completely mixed <sigh> now. Since the header has 4 space settings I guess that is what is desired. I don't think that mScriptsEnabled should default to PR_TRUE. Can you explain that choice? Please also explain why mImageAnimationMode defaults to kNormalAnimMode rather than kDontAnimMode. Perhaps mImageAnimationMode is poorly named? Fix the construction to initialize mImageAnimationMode to imgIContainer::k* rather than some arbitrary integer. in nsEditingSession::TearDownEditorOnWindow, reorder mDoneSetup and docShell initialization (put it in the block with the comment "register callback" which should probably be changed to "unregister" or "remove") Why are you ignoring the return value of SetEditorOnControllers? Add "(void)" in front of a call where you intentionally are ignoring the return value. Add (void) in front of these calls: RemoveSelectionListener RemoveDocumentStateListener Perhaps it's unnecessary but I would expect to see a check that domWindowInt's QI succeeded before dereferencing it to call GetControllers. I don't see a check for docShell succeeding (sgo->GetDocShell()) before dereferencing it. Personally I don't like assignments buried in if checks; please pull out (a couple extra lines won't be bad in this block) the assignment for presContext. Thanks for fixing the PRBool->PRPackedBool. :-) The biggest confusion I have is the poor choice in naming mScriptsEnabled and mImageAnimationMode. I'm removing the review request until the issues above have responses. This patch is pretty close (although I haven't tested it myself). I hope an update will be mosted soon so it can get r= and land.
Attachment #149484 - Flags: review?(akkzilla)
Comment on attachment 149484 [details] [diff] [review] One step closer... please rearrange nsHTMLDocument::SetScriptGlobalObject method to not create the nsIDOMWindow (window) until inside the if (editSession) block. I'm assuming that shell->GetPresContext() calls are not introducing leaks. I recall a while ago when nsDocShell.cpp was 2-spaces per level rather than 4 (I had to redo a patch that had 4 spaces instead of 2). I see that the file is completely mixed <sigh> now. Since the header has 4 space settings I guess that is what is desired. I don't think that mScriptsEnabled should default to PR_TRUE. Can you explain that choice? Please also explain why mImageAnimationMode defaults to kNormalAnimMode rather than kDontAnimMode. Perhaps mImageAnimationMode is poorly named? Fix the construction to initialize mImageAnimationMode to imgIContainer::k* rather than some arbitrary integer. in nsEditingSession::TearDownEditorOnWindow, reorder mDoneSetup and docShell initialization (put it in the block with the comment "register callback" which should probably be changed to "unregister" or "remove") Why are you ignoring the return value of SetEditorOnControllers? Add "(void)" in front of a call where you intentionally are ignoring the return value. Add (void) in front of these calls: RemoveSelectionListener RemoveDocumentStateListener Perhaps it's unnecessary but I would expect to see a check that domWindowInt's QI succeeded before dereferencing it to call GetControllers. I don't see a check for docShell succeeding (sgo->GetDocShell()) before dereferencing it. Personally I don't like assignments buried in if checks; please pull out (a couple extra lines won't be bad in this block) the assignment for presContext. Thanks for fixing the PRBool->PRPackedBool. :-) The biggest confusion I have is the poor choice in naming mScriptsEnabled and mImageAnimationMode. I'm removing the review request until the issues above have responses. This patch is pretty close (although I haven't tested it myself). I hope an update will be mosted soon so it can get r= and land.
ouch; sorry for the double-entry (I was getting a 500 error)
Flags: blocking1.8a6? → blocking1.8a6-
Flags: blocking1.8b?
Flags: blocking-aviary1.1?
Should this bug be reassigned to jst since he has the patch? jst--what is the status on this bug? Can you update your patch so it can land soon?
Flags: blocking1.7.6? → blocking1.7.6-
I'm just freshining this thread to say that nightly builds are still showing this bug, and the level of impact it's having is increasing. My group maintains web tools for the University of Washington, where many campus tools that use the MIDAS extention render people's browsers unusable by our middleware login (pubcookie). This affects all firefox/mozilla users on campus, and the occurance rate is very high, as the middleware is unavoidable and the tools are popular and often required coursework. The posted patches no longer apply smoothly to the codebase, and I haven't the familiarity with C or the mozilla code to do productive work on this. I strongly recommend that this be marked as a blocker.
I just put my vote in for this bug. It causes the course management system LON-CAPA to have problems when a user chooses to edit text with the built-in WYSIWYG editor. http://bugs.loncapa.org/show_bug.cgi?id=2665
Could anyone update the patch, so that it works with the latest trunk builds? And where is jst? Has he disappeared?
(In reply to comment #62) > Could anyone update the patch, so that it works with the latest trunk builds? > And where is jst? Has he disappeared? I'm here, I'm just busy with other work right now. I did want to own this change, I just did what I did in hopes that someone else would pick it up and finish the patch, maybe I'll need to do that myself now, once I get some spare cycles...
(In reply to comment #63) > I'm here, I'm just busy with other work right now. nm, I didn't mean to push you. I just wondered, if you disappeared. > I did want to own this > change, I just did what I did in hopes that someone else would pick it up and > finish the patch, maybe I'll need to do that myself now, once I get some spare > cycles... How about adding the keyword helpwanted for the time being? I'm moving my request for blocking1.8b to blocking1.8b2, since 1.8b is being release soon AFAICS.
Flags: blocking1.8b? → blocking1.8b2?
The initial testcase in this bug enabled designMode on the iframe inline, before the about:blank document had been loaded into the iframe. Editing was still turned on, but for the wrong reasons...
Attachment #174711 - Attachment is patch: false
Attachment #174711 - Attachment mime type: text/plain → text/html
Attached patch diff -w of the above for review. (obsolete) — — Splinter Review
Attachment #174775 - Flags: superreview?(bzbarsky)
Attachment #174775 - Flags: review?(brade)
Comment on attachment 174775 [details] [diff] [review] diff -w of the above for review. >Index: content/html/document/src/nsHTMLDocument.cpp >+nsHTMLDocument::SetScriptGlobalObject(nsIScriptGlobalObject *aGlobalObject) >+{ >+ if (!aGlobalObject && mEditingIsOn && mScriptGlobalObject) { Actually, we can have an editing session set up even when mEditingIsOn is false... Would fixing SetDesignMode() to call TearDownEditorOnWindow when set to false help that? So we're changing from having a single editing session on the root docshell to having per-docshell editing sessions, right? If that works, sounds like a good change to me! sr=bzbarsky with that mEditingIsOn thing addressed.
Attachment #174775 - Flags: superreview?(bzbarsky) → superreview+
Thank you so much for getting this into 1.8 -- this bug has been making me use IE occassionally for some time. Hopefully I can now just use Mozilla! Thanks again!
bz, this makes setting designMode to 'off' really turn off editing, and while testing this out I realized that I don't need the code in nsHTMLDocument::SetScriptGlobal() at all since the editor takes care of tearing itself down now through its progress listener, and if it was enabled due to designMode being set to 'on' it'll unregister itself as a progress listener, not to come back again until asked through midas etc. With this change midas can be turned on and off, and on and off again, it all seems to be working as expected, yay! :)
Attachment #174774 - Attachment is obsolete: true
Attachment #174775 - Attachment is obsolete: true
Attachment #174875 - Flags: superreview?(bzbarsky)
Attachment #174875 - Flags: review?(brade)
Assignee: mkaply → jst
Status: NEW → ASSIGNED
Attachment #174775 - Flags: review?(brade)
Comment on attachment 174875 [details] [diff] [review] Address bz's issues (diff -w). Looks reasonable
Attachment #174875 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 174875 [details] [diff] [review] Address bz's issues (diff -w). This block concerns me (nsHTMLDocument.cpp): + if (aDesignMode.LowerCaseEqualsLiteral("on") && !mEditingIsOn) { + rv = editSession->MakeWindowEditable(window, "html", PR_FALSE); // now that we've successfully created the editor, we can reset our flag mEditingIsOn = PR_TRUE; I don't like to see mEditingIsOn set to true if MakeWindowEditable fails. Also, I'm not sure that we should be setting mEditingisOn to false if someone is scripting and sets DesignMode to true twice. I assume you've tested Composer, Mail Compose, textareas, inputs and any other <editor> uses. >With this change midas can be turned on and off, >and on and off again, it all seems to be working >as expected, yay! :) FABULOUS!!!! THANK YOU!!! r=brade with the above fixes.
Attachment #174875 - Flags: review?(brade) → review+
(In reply to comment #73) > (From update of attachment 174875 [details] [diff] [review] [edit]) [...] > I don't like to see mEditingIsOn set to true if MakeWindowEditable fails. Fixed. > Also, I'm not sure that we should be setting mEditingisOn to false if someone > is scripting and sets DesignMode to true twice. We don't. Setting designMode to "on" while it's already on is a no-op, as is setting it to "off" when it's already off. > I assume you've tested Composer, Mail Compose, textareas, inputs and any other > <editor> uses. Yeah, no problems seen so far with the latest patch. Thanks for the reviews, this is going in...
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Blocks: 197302
Depends on: 284245
Depends on: 287707
which build is this targeted for ?
The next release after the date it was fixed (so Gecko 1.8b2 and all applications based on that).
Flags: blocking1.8b2?
Flags: blocking1.8a6-
Flags: blocking1.7.6-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0-
*** Bug 289488 has been marked as a duplicate of this bug. ***
Could someone probably update the testcases? The links are broken and I have no idea, where a new meta-refresh example could be found.
Load the page http://www.mozilla.org/editor/midasdemo/ Then view the attachment. Does this testcase do what you're looking for?
I'm trying to fix my middleware application to recognize which browsers have this bug and avoid using the midas-based embedded editor in those cases. I'd think that it would be as easy as checking the user-agent string Gecko/20050223 or later, but this bug is affecting Firefox 1.0.2, which claims Gecko/20050317. My guess is that this is due to Firefox 1.0.2 being built from a different branch in CVS that has Gecko enhancements that cause the Gecko version number to be incremented for that branch independently of the main branch. Is this correct? In that case, I'm guessing that this bug fix will make it into Firefox 1.1? If the Gecko version number can't be relied upon, does anyone have any advice for how middleware can check for the presence of this bug in order to avoid it? I'd prefer a solution that works for all Gecko-based browers, including Firefox, Mozilla, Camino, and other Gecko-based browsers not available directly through the Mozilla Foundation.
> Gecko/20050223 That's just the date on which that build was compiled (Feb 23, 2005 in this case), independent of the branch. The branch is indicated by the rv: in the useragent. So, look at the rv: number in combination with the date.
Would I be crazy to try to backport this to Novell's FF 1.0.x builds?
Note that gmail is apparently serving their rich text email editing to FF 1.0.x users, and this will be hurting them.
Note that this patch made designmode not work on blogger.com (bug 284245), and there were some other regressions too. So landing it on 1.7 branch should be done rather carefully...
So there are regressions not mentioned here? Urgh
To be precise, bug 283897 is what I was thinking of.... That's a fun patch too. :(
Depends on: 283897
(In reply to comment #81) > I'm trying to fix my middleware application to recognize which browsers have > this bug and avoid using the midas-based embedded editor in those cases. > > I'd think that it would be as easy as checking the user-agent string > Gecko/20050223 or later, but this bug is affecting Firefox 1.0.2, which > claims Gecko/20050317. My guess is that this is due to Firefox 1.0.2 being > built from a different branch in CVS The second half of bug 65764 comment 18 had a proposed solution to the branch problem. The main thing was to make the date a source (pull) date as originally envisioned rather than a build date and then increment down the branch. The counter argument was that any "serious" bug would often get fixed on both the branch and trunk around the same time, and leaving it as is was easier. Maybe for Gecko 2.0... > I'd prefer a solution that works for all Gecko-based browers, including > [...] other Gecko-based browsers not available directly > through the Mozilla Foundation. Another advantage of a source date is that someone building from a release tag next month will get the same (or similar) Gecko token as the official release, rather than the current build date which has nothing to do with which release might have been built.
*** Bug 294102 has been marked as a duplicate of this bug. ***
QA Contact: bugzilla → nobody
*** Bug 311112 has been marked as a duplicate of this bug. ***
*** Bug 314444 has been marked as a duplicate of this bug. ***
Depends on: 335216
Depends on: 336160
Same thing is happening to me. I don't know how you can call it resolved.
If you're seeing something like this, please file a separate bug with a testcase and steps to reproduce. Make sure to clearly state which version of Gecko (or Firefox/Seamonkey/whatever) you're using. Please cc me on that bug.
Blocks: 234844
QA Contact: nobody → editor
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: