After "Close other tabs" tab's context menu contains scrollbars/arrows.

VERIFIED FIXED in mozilla1.8.1

Status

()

Core
XUL
--
major
VERIFIED FIXED
11 years ago
9 years ago

People

(Reporter: stephend, Assigned: Martijn Wargers (dead))

Tracking

(5 keywords)

Trunk
mozilla1.8.1
fixed-seamonkey1.0.5, fixed-seamonkey1.1b, fixed1.8.0.7, fixed1.8.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 -
blocking1.8.0.7 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 7 obsolete attachments)

6.65 KB, text/plain
Details
2.70 KB, patch
mconnor
: approval1.8.1+
Details | Diff | Splinter Review
2.70 KB, patch
Details | Diff | Splinter Review
2.02 KB, patch
mano
: review+
Details | Diff | Splinter Review
Build ID: 2006-06-09-18 of SeaMonkey trunk on Windows XP.

Summary: After "Close other tabs" tab's context menu contains scrollbars.

Steps to Reproduce:

1.  On Windows, do a CTRL-T until you fill up the screen horizontally.
2.  Right-click on a tab and choose "Close other tabs".
3.  Open a new tab, context-click it, and look at the context menu.

Expected Results:

Context menu _without_ vertical scrollbars appears.

Actual Results:

Context menu with scrollbars appears.

Comment 1

11 years ago
This regressed between 2006-05-24-09 and 2006-05-25-09.
I took me a few tries.  Does the tab you don't close have to be not-the-first tab?
(In reply to comment #2)
> I took me a few tries.  Does the tab you don't close have to be not-the-first
> tab?
> 

Looks like you have to do it on a background tab.

Comment 4

11 years ago
Another way to reproduce this bug is:

1. Right-click a Live Bookmark and select 'Open All in Tabs'
2. Right-click on a tab and select 'Close Other Tabs'
3. Open a new tab, Right-click it and look at the menu.

Tested on Windows XP and Linux and bug is easily reproduced. If 'Always show the tab bar' is selected in preferences, this bug does not occur.

Comment 5

11 years ago
I was also able to more reliably reproduce the bug if the Open and Close multiple tabs warnings were enabled.
(Assignee)

Comment 6

11 years ago
This was caused by the fix for bug 336999. I can see this bug now also in Firefox1.5.0.6 (2006-8-14 build).

With a 1.8.1 branch build, I get this error in the js console when this happens:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIScrollBoxObject.getScrolledSize]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://global/content/bindings/scrollbox.xml :: _updateScrollButtonsDisabledState :: line 144"  data: no]
Blocks: 336999
(Assignee)

Comment 7

11 years ago
Created attachment 233762 [details] [diff] [review]
ugly fix1

This fixes it, by using try..catch, which is ugly, but I don't know of a way to fix this otherwise.
(Assignee)

Comment 8

11 years ago
Created attachment 233763 [details] [diff] [review]
ugly fix2

Another ugly fix option.

Forgot to mention, I can reproduce this 100% when following comment 4 and comment 5.
So how come getScrolledSize is throwing?  At what point is this code being called, compared to nsCSSFrameConstructor::AttributeChanged?  For example, what's the callstack to getScrolledSize (on the C++ side, before we end up in the chrome JS)?
Component: Tabbed Browser → XP Toolkit/Widgets: XUL
Flags: blocking1.9?
Flags: blocking1.8.1?
Flags: blocking1.8.0.7?
Drivers don't feel that this is a serious enough issue (it's visual only, not a functionality regression) to warrant blocking the release. However, we'd take a well baked, low-risk patch.
Flags: blocking1.8.1? → blocking1.8.1-
Whiteboard: [would take patch]
Ditto 1.8.1 drivers, especially as there's no owner on the bug. Please nominate the patch you want for 1.8.0 once it's landed on the trunk.
Flags: blocking1.8.0.7? → blocking1.8.0.7-
(Assignee)

Comment 12

11 years ago
Created attachment 233984 [details]
backtrace from branch debug build

I added an assertion in my debug build when nsIFrame* scrolledBox = GetScrolledBox(this); returns null in nsScrollBoxObject::GetScrolledSize
This is the backtrace I get with the steps to reproduce.
Note that I get this assertion after I clicked on the warning dialog, which is odd, because the context menu has disappeared by long since then.
So basically we're calling _updateScrollButtonsDisabledState off an overflow or underflow event handler, right?  Which is handled right after reflow completes?

And sometime in there we destroyed the frame, after posting the event, right?  So the box object can't find the frame, etc...

Maybe the try/catch is indeed the right approach here.  Or canceling the DOM event when the frame is destroyed, perhaps?  It really doesn't make sense to fire overflow/underflow when the frame is dead.

Of course it's not clear to me why frame is dying somewhere in the middle of reflow... unless it's dying after we've dispatched the DOM event while the JS is running or something?  That can certainly happen on trunk, since nsBoxObject::GetFrame will flush frames.  In fact, that seems like the most likely scenario....

Perhaps HandlePostedDOMEvents should flush frames on that presshell before processing the events?  And we should have a way to "unpost" an event that scrollframes would use?
(Assignee)

Comment 14

11 years ago
(In reply to comment #13)
> Maybe the try/catch is indeed the right approach here.  Or canceling the DOM
> event when the frame is destroyed, perhaps?  It really doesn't make sense to
> fire overflow/underflow when the frame is dead.

Should I ask review on the patch? I don't know a better way, but I would prefer if we didn't regress this bug on the 1.8.0.x branch also.

> Should I ask review on the patch? 

Yes.  Probably from the xpfe/toolkit owners.  I thought about it some more, and there is no way we can guarantee that the frame is still alive by the time the overflow/underflow handler is called (e.g. it could have been killed by a capturing handler higher up; in this case we can't prevent the child handler being called either, really).  So the UI code needs to deal with that eventuality somehow.
(Assignee)

Comment 16

11 years ago
Comment on attachment 233763 [details] [diff] [review]
ugly fix2

Ok, asking review then.
Seamonkey doesn't need a fix because it doesn't seem to have code for disabled state for the scrollbox, currently.
Maybe a comment in the code why try..catch is needed here should be added?
Attachment #233763 - Flags: review?(bugs.mano)
Boris, could we somehow face the scenario you've described in comment 13 on underflow?
Comment on attachment 233763 [details] [diff] [review]
ugly fix2

See comment 17. Also:

>Index: toolkit/content/widgets/scrollbox.xml
>===================================================================

>       <handler event="overflow"><![CDATA[
>         // filter underflow events which were dispatched on nested scrollboxes
>         if (event.target != this)
>           return;
> 
>-        this._scrollButtonUp.collapsed = false;
>-        this._scrollButtonDown.collapsed = false;
>-        this._updateScrollButtonsDisabledState();
>+        try {
>+          this._scrollButtonUp.collapsed = false;
>+          this._scrollButtonDown.collapsed = false;

nit: put these outside of the try block.

>+          this._updateScrollButtonsDisabledState();
>+        } 
>+        catch(e) {
>+          this._scrollButtonUp.collapsed = true;
>+          this._scrollButtonDown.collapsed = true;

Please add a comment here explaining the reason for hiding the buttons (and also when would _updateScrollButtonsDisabledState throw).
Attachment #233763 - Flags: review?(bugs.mano) → review-
I think we could hit this for underflow, yes.  How did we _use_ to handle this?  Before the fix for bug 336999 we probably didn't fire the underflow or overflow event at all.  What happened then?
(Assignee)

Comment 20

11 years ago
Created attachment 234308 [details] [diff] [review]
ugly fix2b

Like this?
Attachment #233762 - Attachment is obsolete: true
Attachment #233763 - Attachment is obsolete: true
Attachment #234308 - Flags: review?(bugs.mano)
Martijn, see comment 19.
(Assignee)

Comment 22

11 years ago
(In reply to comment #21)
> Martijn, see comment 19.

Yes, I know, but I don't know of a practical situation in which a user is able to hit this and sees scrollbars in his scrollbox afterwards.
Anyway, if you want try..catch blocks around that code too, I can do that.
(Assignee)

Comment 23

11 years ago
Created attachment 234311 [details] [diff] [review]
ugly fix3

So like this. I haven't tested this, but I don't know of a case where underflow is fired, while this.ensureElementIsVisible is throwing.
I could create such a testcase, I guess, but that would be an artificial situation.
*** Bug 349334 has been marked as a duplicate of this bug. ***
Comment on attachment 234311 [details] [diff] [review]
ugly fix3

>Index: toolkit/content/widgets/scrollbox.xml
>===================================================================

>-        var childNodes = document.getAnonymousNodes(this._scrollbox);
>-        if (childNodes && childNodes.length) {
>-          this.ensureElementIsVisible(childNodes[0]);
>-          if (childNodes.length > 1)
>-            this.ensureElementIsVisible(childNodes[childNodes.length-1]);
>+        try {
>+          // See bug 341047 and see comments in overflow handler of why try..catch is needed here

nit: s/of why/as to why/. Also, 80 chaacterrs per line.

>+          var childNodes = document.getAnonymousNodes(this._scrollbox);
>+          if (childNodes && childNodes.length) {
>+            this.ensureElementIsVisible(childNodes[0]);
>+            if (childNodes.length > 1)
>+              this.ensureElementIsVisible(childNodes[childNodes.length-1]);

while you're here, please change this to

if (childNodes.length > 0)
  this.ensureElementIsVisible(childNodes[0]);

the last-child thing isn't need here.


...
>+        try {
>+          // See bug 341047, the overflow event is firing when the scrollbox already is mostly destroyed.
>+          // this causes some code in _updateScrollButtonsDisabledState() to throw an error.
>+          // It also means that the scrollbarbuttons were uncollapsed when that should not be happening,
>+          // because the whole overflow event should not be happening in that case.

"dispatched". Again, 80 characters per line please.


r=mano otherwise.
Attachment #234311 - Flags: review+
Attachment #234308 - Attachment is obsolete: true
Attachment #234308 - Flags: review?(bugs.mano)
(Assignee)

Comment 26

11 years ago
This is also a problem in Seamonkey it seems, see bug 349334. It doesn't have the _updateScrollButtonsDisabledState code which throws the exception, but the overflow event is still fired when the popup is destroyed which causes the scrollbars.
(In reply to comment #26)
> This is also a problem in Seamonkey it seems, see bug 349334. It doesn't have
> the _updateScrollButtonsDisabledState code which throws the exception, but the
> overflow event is still fired when the popup is destroyed which causes the
> scrollbars.

Er, also?  SeaMonkey was noted in comment 0 ;-)
Flags: blocking1.8.1- → blocking1.8.1?
Whiteboard: [would take patch] → [has patch]
Comment on attachment 234311 [details] [diff] [review]
ugly fix3

Matijn, please land this on trunk asap, thanks.
Attachment #234311 - Flags: approval1.8.1?
(Assignee)

Comment 29

11 years ago
Created attachment 234775 [details] [diff] [review]
for check-in (checked in on trunk)

(In reply to comment #27)
> Er, also?  SeaMonkey was noted in comment 0 ;-)

Oops! I probably should read the bug comments ;)
So Seamonkey needs a similar (or even worse) hack.
Attachment #234311 - Attachment is obsolete: true
Attachment #234311 - Flags: approval1.8.1?
(Assignee)

Comment 30

11 years ago
Checking in scrollbox.xml;
/cvsroot/mozilla/toolkit/content/widgets/scrollbox.xml,v  <--  scrollbox.xml
new revision: 1.20; previous revision: 1.19
done

Checked in on trunk. Leaving bug open for Seamonkey.

Comment 31

11 years ago
The checkin on trunk seems to have unbalanced {}'s.
(Assignee)

Comment 32

11 years ago
(In reply to comment #31)
> The checkin on trunk seems to have unbalanced {}'s.

Sorry, it is caused here:
+          if (childNodes && childNodes.length) {
+            if (childNodes.length > 0)
+              this.ensureElementIsVisible(childNodes[0]);
+        }
It needs an extra } before the final }

I'm afraid I can fix this only after 5/6 hours, sorry about that.
Driver's decision is the same as in comment 10; once the patch is on trunk and well baked, please nominate for approval1.8.1?
Flags: blocking1.8.1? → blocking1.8.1-
(Assignee)

Comment 34

11 years ago
Fix checked in for the stupid error mentioned in comment 31.
(Assignee)

Updated

11 years ago
Blocks: 349897
Summary: After "Close other tabs" tab's context menu contains scrollbars. → After "Close other tabs" tab's context menu contains scrollbars/arrows.
Attachment #234775 - Attachment description: for check-in → for check-in (checked in on trunk)
Attachment #234775 - Flags: approval1.8.1?
Comment on attachment 234775 [details] [diff] [review]
for check-in (checked in on trunk)

a=mconnor on behalf of drivers for checkin to 1.8 branch.
Attachment #234775 - Flags: approval1.8.1? → approval1.8.1+

Updated

11 years ago
Whiteboard: [has patch] → [has patch][checkin needed (1.8 branch)]
*** Bug 349897 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 37

11 years ago
Created attachment 235319 [details] [diff] [review]
patch for 1.8 branch
[Checkin: Comment 38]

This is the 1.8.1 branch patch, which I'll check in.
(Assignee)

Comment 38

11 years ago
Checked in on the 1.8.1 branch. Is the patch something that should be worthy of the 1.5.0.8 branch?
Keywords: fixed1.8.1
I think so, yes.
(Assignee)

Comment 40

11 years ago
Comment on attachment 235319 [details] [diff] [review]
patch for 1.8 branch
[Checkin: Comment 38]

It's really a shame that the patch for bug 336999, that's causing this bug is on the 1.8.0.7 branch.
Now, this will be broken on the 1.8.0.7 branch and could possibly be fixed again on the 1.8.0.8 branch, if this patch is approved.
Attachment #235319 - Flags: approval1.8.0.8?
I think you should request approval for 1.8.0.7... is there a reason not to?
(Assignee)

Comment 42

11 years ago
Comment on attachment 235319 [details] [diff] [review]
patch for 1.8 branch
[Checkin: Comment 38]

I thought the 1.8.0.7 tree was already closed, but I can always try, I guess.
Attachment #235319 - Flags: approval1.8.0.8? → approval1.8.0.7?
Comment on attachment 235319 [details] [diff] [review]
patch for 1.8 branch
[Checkin: Comment 38]

approved for 1.8.0 branch, a=dveditz for drivers

Code freeze is today (+weekend if necessary) for a candidate build Monday. Please check in ASAP.
Attachment #235319 - Flags: approval1.8.0.7? → approval1.8.0.7+
Assignee: nobody → martijn.martijn
(Assignee)

Comment 44

11 years ago
Oh, stuff on the 1.8.0.7 branch is more or less the same as Seamonkey code, so it needs a different patch. Not sure yet how to fix that in the best way.
(Assignee)

Comment 45

11 years ago
Created attachment 235577 [details] [diff] [review]
patch for 1.8.0.x branch
[Checkin: Comment 52]

So something like this?
boxObject.width returns 0 when this is happening, so a check for that, prevents this from happening.
Attachment #235577 - Flags: review?(bugs.mano)
Comment on attachment 235577 [details] [diff] [review]
patch for 1.8.0.x branch
[Checkin: Comment 52]

r=mano
Attachment #235577 - Flags: review?(bugs.mano) → review+
(Assignee)

Comment 47

11 years ago
Comment on attachment 235577 [details] [diff] [review]
patch for 1.8.0.x branch
[Checkin: Comment 52]

This needs approval1.8.0.7 because this is a different patch.
Attachment #235577 - Flags: approval1.8.0.7?
Created attachment 235695 [details] [diff] [review]
(Gv1-XPFE) <scrollbox.xml>

Ports TK-180 patch to SeaMonkey.


[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1b2) Gecko/20060827 SeaMonkey/1.1b] (nightly) (W98SE)

In my local install,
I added an |else { alert(...); }| to each "function" to check whether this case was happening,
and, shortly after, I saw my first case in the |overflow| function:
immediately "after" closing a tab.
Then, it seems this fix is appropriate for SeaMonkey too :-)
Attachment #235695 - Flags: superreview?(neil)
Attachment #235695 - Flags: review?(jag)
Attachment #235319 - Attachment description: patch for 1.8 branch → patch for 1.8 branch [Checkin: Comment 38]
Whiteboard: [has patch][checkin needed (1.8 branch)] → [has patch]

Comment 49

11 years ago
Comment on attachment 235695 [details] [diff] [review]
(Gv1-XPFE) <scrollbox.xml>

+        // In that code, the below code should not be executed.

I wonder if "In that case, the ..." was intended.
Attachment #235695 - Flags: review?(jag) → review+
Comment on attachment 235577 [details] [diff] [review]
patch for 1.8.0.x branch
[Checkin: Comment 52]

a=dveditz on this 1.8.0 version, then, but may not make it (about 12 hours to go).
Attachment #235577 - Flags: approval1.8.0.7? → approval1.8.0.7+
Attachment #235319 - Flags: approval1.8.0.7+
(In reply to comment #49)
> (From update of attachment 235695 [details] [diff] [review] [edit])
> +        // In that code, the below code should not be executed.
> 
> I wonder if "In that case, the ..." was intended.

I did too, but I decided to simply copy it as it was.
Martijn, what do you think ?
(Assignee)

Comment 52

11 years ago
(In reply to comment #51)
> > I wonder if "In that case, the ..." was intended.
> 
> I did too, but I decided to simply copy it as it was.
> Martijn, what do you think ?

Argh! No, that should be: "In that case". I've fixed that comment before I checked in the "patch for 1.8.0.x branch" patch in the 1.8.0.7 tree.
Sorry for not providing a Seamonkey patch, I was more or less busy with getting the Firefox patches in. I was planning on doing that afterwards.
Keywords: fixed1.8.0.7

Updated

11 years ago
Attachment #235695 - Flags: superreview?(neil) → superreview+

Comment 53

11 years ago
Comment on attachment 235695 [details] [diff] [review]
(Gv1-XPFE) <scrollbox.xml>

>+        // See bug 341047 and comments in overflow handler why this check is
>+        // needed.
Nit: See bug 341047 and comments in overflow handler as to why this check is needed.

>+        // See bug 341047, the overflow event is dispatched when the scrollbox
>+        // already is mostly destroyed, that should not be happening.
Nit: See bug 341047, the overflow event is dispatched when the scrollbox is already mostly destroyed, which should not be happening.

>+        // That is what this boxObject check is doing.
Nit: That is what this boxObject check does.

Comment 54

11 years ago
Comment on attachment 235695 [details] [diff] [review]
(Gv1-XPFE) <scrollbox.xml>

Alternative wording:
         // XXX Workaround for unexpected events dispatched
         // during scrollbox destruction (bug 341047).
Created attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

Gv1-XPFE, with comment 54 suggestion,
and a reversed test.

'approval1.8.1=?': (XPFE only)
Simple UI regression fix, no risk. (see comment 40)

'approval1.8.0.7=?' / 'approval1.8.0.8=?': (XPFE only)
I believe it's too late for 1.8.0.7, but may be not for a "SeaMonkey" only patch !?
Attachment #236524 - Flags: superreview?(neil)
Attachment #236524 - Flags: review?(jag)
Attachment #236524 - Flags: approval1.8.1?
Attachment #236524 - Flags: approval1.8.0.8?
Attachment #236524 - Flags: approval1.8.0.7?
Attachment #235695 - Attachment is obsolete: true
Attachment #235577 - Attachment description: patch for 1.8.0.x branch → patch for 1.8.0.x branch [Checkin: Comment 52]
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

a1.8.0.x are Fx/Tb only. There's an a1.7.14 flag (i'm not sure whether or not it's still used.)
Attachment #236524 - Flags: approval1.8.1?
Attachment #236524 - Flags: approval1.8.0.7?
Attachment #236524 - Flags: approval1.8.0.8?
(In reply to comment #56)
> (From update of attachment 236524 [details] [diff] [review] [edit])
> a1.8.0.x are Fx/Tb only. There's an a1.7.14 flag (i'm not sure whether or not
> it's still used.)

Then, there must be missing flags,
as a1.7.14 is for ("retired") Mozilla Application Suite.

What are the flags to use for Core bugs (like this one) ?

NB: There must also be some news that I missed, as I used to do like that, and it went well, until now...

Comment 58

11 years ago
(In reply to comment #56)
> (From update of attachment 236524 [details] [diff] [review] [edit])
> a1.8.0.x are Fx/Tb only.

Bullshit. Sorry for the strong language, but you should get informed before posting nonsense.

a1.8.[0.]x are applicable for all core changes (or better, all drivers-governed parts of mozilla.org code).
For SeaMonkey-spcific patches in relevant products on bugzilla, there are appropriate seamonkey-council-governed approval-seamonkey* flags, but core code is governed by drivers and therefore a1.8.* flags are correct to use.

Comment 59

11 years ago
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

Resetting approval? flags
Attachment #236524 - Flags: approval1.8.1?
Attachment #236524 - Flags: approval1.8.0.8?
Attachment #236524 - Flags: approval1.8.0.7?

Comment 60

11 years ago
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

Not my preferred style, but jag can r+sr if he likes it
Attachment #236524 - Flags: superreview?(neil) → superreview?(jag)

Comment 61

11 years ago
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

If these events are unexpected, does that mean there's a bug somewhere on making them not fire?

If so, then I like this patch as it'll make it easier to remove these lines when that bug gets fixed, and it makes it clear this code isn't part of the main purpose of that handler.

If on the other hand those events aren't unexpected I like the previous patch better.
(Assignee)

Comment 62

11 years ago
(In reply to comment #61)
> If these events are unexpected, does that mean there's a bug somewhere on
> making them not fire?

These events are unexpected, I haven't filed a bug about it yet. I was trying to get a testcase that reproduces the bug, but failed.

Comment 63

11 years ago
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

clearing the nom flag on the 1.8.1 branch.  Please make sure you have all reviews and patches have baked on trunk before asking for approval.
Attachment #236524 - Flags: approval1.8.1?

Comment 64

11 years ago
Comment on attachment 236524 [details] [diff] [review]
(Gv2-XPFE) <scrollbox.xml>

r+sr if you drop the {}s.
Attachment #236524 - Flags: superreview?(jag)
Attachment #236524 - Flags: superreview+
Attachment #236524 - Flags: review?(jag)
Attachment #236524 - Flags: review+
Created attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

Gv2, with comment 64 suggestion(s).

For checkin.
Attachment #236524 - Attachment is obsolete: true
Attachment #236524 - Flags: approval1.8.0.8?
Attachment #236524 - Flags: approval1.8.0.7?
Whiteboard: [has patch] → [checkin needed: Gv2b-XPFE] [has patch]
Target Milestone: --- → mozilla1.8.1
Comment on attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

seamonkey-only, approved for the 1.8.0 branch in consultation with the seamonkey-council, a=dveditz

Do you need this on the 1.8 branch also?
Attachment #236999 - Flags: approval1.8.0.7+
Comment on attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

Yes, we do.
Attachment #236999 - Flags: approval1.8.1?
Whiteboard: [checkin needed: Gv2b-XPFE] [has patch] → [checkin needed (Trunk & 1.8.0 branch): Gv2b-XPFE] [has patch]
Comment on attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

a=beltzner on behalf of 181drivers
Attachment #236999 - Flags: approval1.8.1? → approval1.8.1+

Comment 69

11 years ago
If the xpfe patch gets landed until about tomorrow noon PDT, we can ship it in SeaMonkey 1.0.5, as we need to respin builds for that release anyways.

Updated

11 years ago
Keywords: fixed-seamonkey1.0.5

Comment 70

11 years ago
Comment on attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

I landed this on the 1.8.0 branch although I had to merge it (branch still has preventBubble)

Comment 71

11 years ago
Comment on attachment 236999 [details] [diff] [review]
(Gv2b-XPFE) <scrollbox.xml>
[Checkin: Comment 70 & 71]

I landed this on trunk and 1.8 branch
Attachment #236999 - Attachment description: (Gv2b-XPFE) <scrollbox.xml> → (Gv2b-XPFE) <scrollbox.xml> [Checkin: Comment 70 & 71]
Attachment #236999 - Attachment is obsolete: true
*PC/WXP -> All/All, per bug 349897.

(In reply to comment #62)
> These events are unexpected, I haven't filed a bug about it yet. I was trying
> to get a testcase that reproduces the bug, but failed.

I believe you can file that bug yet:
even if we don't have a testcase, we know the bug is there.
No longer blocks: 349897
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9?
Keywords: fixed-seamonkey1.1b
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Whiteboard: [checkin needed (Trunk & 1.8.0 branch): Gv2b-XPFE] [has patch]
(Assignee)

Updated

11 years ago
Depends on: 351938
(Assignee)

Comment 73

11 years ago
(In reply to comment #72)
> I believe you can file that bug yet:
> even if we don't have a testcase, we know the bug is there.

Ok, I filed bug 351938 for it.

No longer depends on: 351938
(Assignee)

Updated

11 years ago
Depends on: 351938
Verified FIXED using SeaMonkey trunk build 2006-09-10-08 under Windows XP; I was no longer able to reproduce this.  If anybody sees this again on trunk or branch, please do reopen this bug.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: tabbed-browser → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.